FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
75% Positive
Analyzed from 2905 words in the discussion.
Trending Topics
#calendar#gregorian#date#dates#julian#https#datetime#using#days#org

Discussion (49 Comments)Read Original on HackerNews
> DateTime is a class for the representation of date/time combinations, and is part of the Perl DateTime project.
> It represents the Gregorian calendar, extended backwards in time before its creation (in 1582). This is sometimes known as the "proleptic Gregorian calendar". In this calendar, the first day of the calendar (the epoch), is the first day of year 1, which corresponds to the date which was (incorrectly) believed to be the birth of Jesus Christ
Always RTFM.
Edit: I double-checked, and while this was not in the docs in the first release, it _was_ in the docs as of 2015.
https://metacpan.org/pod/DateTime
But it is typically used when referring to events located in areas with no calendar system familiar to modern readers, most notably the Maya calendar. Maya Long Count dates are typically converted to the proleptic Gregorian calendar.
Also, many modern historical writings will display both Julian and Gregorian dates, particularly for dates around when the calendars were changing or when context is unclear (e.g. a historical figure who was born in an area with one calendar and died in an area with another calendar).
Fun fact: Greece was still using the old Julian calendar as of 1928, so it's entirely possible that you'll see dates on relatively recent Greek documents that are up to 14 days off from the calendar the rest of the world was using. Civil timekeeping is just a mess.
In science-related code, I can image a case for calculating things like seconds elapsed across a very long time period. But in that case you're not really dealing with dates. Instead, you want something like the Unix epoch, but probably with an earlier epoch start.
There may be some very niche cases for pre-1582 dates in code that I'm not thinking of. But I'd expect that in this case you're going to put a lot of effort into finding the right libraries, or you might just write your own code.
Regardless, the linked blog post says of DateTime: "Unfortunately, like Python, a proper error message for impossible Gregorian dates is notably absent."
But this is just wrong. There's no "proper error message" to emit. The code works as documented.
People writing knowledge base software, like Wikidata. It's helpful to be able to display historical dates in any desired calendar, and also to be able to do date arithmetic between any two arbitrary dates.
I find these things so much easier to think about if you consider the change as a change from one calendar system to another calendar system. Those 10 days certainly exist, in both calendar systems, they just represent different points in time. I.e., I think it's easier to just consider both calendar systems as the rules, extended forward & backwards infinitely ("proleptic"). Some people switched from a Julian calendar to a Gregorian one in 1582.
"Some people did not experience days with these labels in some areas of the world" … I get where it's coming from, but it's not how I'd build a library.
If you worry about the switch, then you have to ask "which switch?" which TFA only lightly touches on. The 1582 one is famous, of course, but not everyone switched, and other parts of the worlds switched as time went on, to as late as 1918, when Russia switched.[1] (And you can see other messiness in that table, too.)
Needing to deal with it is niche enough that I think most language std libs should implement the proleptic Gregorian calendar, and let an application whose niche requires it deal with the switch (& whichever switch it requires).
[1] https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_...
Thanks. I haven’t known that countries switched in different years.
Gregorian calendar is just one piece.
https://en.wikipedia.org/wiki/Civil_calendar
Eighteen countries use another calendar alongside the Gregorian calendar…
The afternotes at the end of the post are worth reading; people have sent me various qualifications and corrections over the years.
(OpenBSD)
(Ubuntu Linux)1582 is Catholic Europe
1700 or 1701 is Protestant Europe
1752 is Great Britain and its colonies which include USA
1918 is Russia
1923 Greece
https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...
Such a flag day didn't involve removing days from one calendar or the other, it switched between them.
I wouldn't say it's it's straightforward to convert between them, either. The Gregorian calendar was first adopted in 1582, but the UK and it's colonies didn't follow suit until 1752. Russia didn't convert until 1918, and Greece didn't switch until 1923. We're just over 100 years out from active use of the Julian calendar. So you have to know who the speaker is and where they are or where they are from to know what they mean.
Since these places switched at different times, they had to skip a different number of days. It was 10 in the 16th century. It was 13 in the 20th!
If you're reading a journal by a British man who lived in Russia through the end of the Great War and then moved to Greece in 1920, what does he mean when he's talking about a lunar eclipse he just witnessed?
If you are talking about a historical event from Egypt in 500 BCE, you would say "this happened in 500 BCE", not "this happened in year 26 of the 27th dynasty".
The distinction is important in the context of doing historical research, but it is no more appropriate to write dates in secondary sources using the Julian calendar than it would be to try to explain Egyptian history by spouting hieroglyphics at people.
1752 is late enough that Benjamin Franklin, George Washington, Thomas Jefferson and others were born before that change.
I think that’s the reason that programming languages tend to adopt the proleptic Gregorian calendar and leave it up to the programmer to figure out when the calendar was adopted in the countries they care about.
Except that countries apparently had to answer various questions when they adopted the Gregorian calendar, and they didn’t all chose the same answers. Ideally, we’d have something like tzdb but for calendar adoption. But I guess the need doesn’t come up all that often.
> In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead.
https://lwn.net/Articles/669022/
Technically, they switched to the Revised Julian[0] calendar, not the Gregorian. Also, it was only some of the churches making up Eastern Orthodoxy that switched; others remain on the Julian calendar to this day, and all of them still use the Julian calendar to calculate the date of Pascha.
[0] https://en.wikipedia.org/wiki/Revised_Julian_calendar
[1] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
And, frankly, there are other problems to deal with beyond correctly handling the Julian/Gregorian switch. In Nelson's Navy, for example, the new day started at noon rather than midnight as we'd expect. AM could be June 1st, PM could be June 2nd, and both could be Tuesday.
And then there are lots of historical events with dates like "on or about August 6th" or "mid-September" or the "in the Fall of".
Trying to deal with historical dates in what a programmer would consider a perfectly correct way is something of a fool's game.
In our Dip (in house db) client library, we built what we called a policy that auto selects partitions based on every crud operations. The policies can be specified once for each collection in collections.json based on fields or query.
So for policies where partition involves the date type fields, be it range or fixed dates, it was incredibly hard to generate universal date names from ranges.
The policy mechanism was finished fairly quickly as Dip is inherently distributed first. But reasoning about date names was so incredibly hard.
The missing dates mentioned in the article did come up during development adding to the woes.
But the upside now is that application code no longer worries about the distributed partitions. Policy handles that. Some sort of architecture as code. Don't know whether AAC is an existing term or whether we coined it.
Instead of flipping the switch in the 1500s... or 1700s... they instead did a slow roll out until they finally flipped the switch and did a big leap.
https://www.americanscientist.org/article/date-distinctions
https://en.wikipedia.org/wiki/List_of_non-standard_dates#Feb...
Tried using ncal like in the examples in that blog post, but it did not work correctly using either Julian or Gregorian. Of course the Swedish calendar from 1700-1712 was neither, but somewhere in-between, because of the (failed) attempt to gradually move from one to the other.
Meta: one can also link to this article, which redirects:
* https://en.wikipedia.org/wiki/February_30
tl;dr - ActiveSupport::TimeWithZone used absolute seconds counting to determine dates while DateTime used a proper Gregorian calendar. This means dates before October 15, 1582 have different internal values when compared.
The behavior showed up because a test was using a DateTime value to set a MySQL DATETIME column to the DB minimum value, which is 1000-01-01 00:00:00, and then comparing the DB record attribute to the original variable used to set it.
Something like:
I "discovered" the missing Gregorian dates when I wrote a loop counting forward in time from Jan 1, 1000 until the corresponding TimeWithZone and DateTime records returned true when compared with ==.imo, if i am using Georgian i want that system even retroactively, just like projecting a date back into the stone age. I don't care that a particular geography or culture changed calendars.
So I suppose what is really going on is that some libraries are using Georgian consistently, and others are using some hybrid "civic" calendar that tracks what the romans and the catholics were using, so dates in history books make sense.
I’ll draft a Dubia so that when future popes change the calendar they will include a representative code sample and details about how we handle this.
(It’s important to remember that the pope and friends were operating much more like an international standards body than a religious leader when doing things like this.)
And if there is a contract dated to the 6th October 1582, that does raise questions about its legitimacy (though in general misdating a contract does not void it, it would merely be one point of evidence in your argument that it's a forgery, just like using a particular font in a modern printed contract)
It's one of those "well technically" things programmers love to obsess over and the judge just says "everyone knows what was meant, stop being an idiot."
Yeah there are a lot of examples of dates being written two ways on the same document/artifact. In the Anglosphere there are two changes that happened close together: the movement of the new year from Lady Day to the first of January, and the Julian/Gregorian calendar jump, so that confounds things slightly. https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
'A date object represents a date (year, month and day) in an idealized calendar, the current Gregorian calendar indefinitely extended in both directions.'
'This matches the definition of the “proleptic Gregorian” calendar in Dershowitz and Reingold’s book Calendrical Calculations.'
https://docs.python.org/3/library/datetime.html#id2 https://docs.python.org/3/library/datetime.html#id5
Whereas Ruby has proleptic Gregorian Time, but civic DateTime:
https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime....
It would natively display "Future" if the file timestamp was ahead of the system clock, but you could also add dates. I remember seeing directory listings like