Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999? If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it. I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times. ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense. So my question is, is there any technical problem in supporting the entire 0 - 9999 range? If not, then my next question would be, what else would speak against supporting the 0 - 9999 range? If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400? Cheers, V.
The lower limit is more or less explained in the documentation http://www.boost.org/doc/libs/1_62_0/doc/html/date_time/gregorian.html
The implemented calendar is a "proleptic Gregorian calendar" which extends dates back prior to the Gregorian Calendar's first adoption in 1582. The current implementation supports dates in the range 1400-Jan-01 to 9999-Dec-31. Many references will represent dates prior to 1582 using the Julian Calendar, so caution is in order if accurate calculations are required on historic dates. See Calendrical Calculations by Reingold & Dershowitz for more details. Date information from Calendrical Calculations has been used to cross-test the correctness of the Gregorian calendar implementation.
-- View this message in context: http://boost.2283326.n4.nabble.com/gregorian-date-limited-to-years-1400-9999... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2016-12-23 10:29, alanbirtles2 wrote:
The lower limit is more or less explained in the documentation http://www.boost.org/doc/libs/1_62_0/doc/html/date_time/gregorian.html
The implemented calendar is a "proleptic Gregorian calendar" which extends dates back prior to the Gregorian Calendar's first adoption in 1582. The current implementation supports dates in the range 1400-Jan-01 to 9999-Dec-31. Many references will represent dates prior to 1582 using the Julian Calendar, so caution is in order if accurate calculations are required on historic dates. See Calendrical Calculations by Reingold & Dershowitz for more details. Date information from Calendrical Calculations has been used to cross-test the correctness of the Gregorian calendar implementation.
Hi, No, this is not an answer to the question. The documentation explains that one has to be cautious with dates prior to 1582 but it does not explain why the earliest date supported is 1400 and not for example 0. I am also curious why this is the case.
On Thu, Dec 22, 2016 at 2:58 PM, Viacheslav Usov <via.usov@gmail.com> wrote:
Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999?
If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it.
I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times.
ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense.
So my question is, is there any technical problem in supporting the entire 0 - 9999 range?
If not, then my next question would be, what else would speak against supporting the 0 - 9999 range?
If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400?
Cheers, V.
My original message was sent just before the holiday season, which might be why there was not much feedback. I am still hoping to get some more feedback. Thanks, V.
On 12/22/2016 03:58 PM, Viacheslav Usov wrote:
Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999?
Not an answer, but we also needed dates outside the supported range. In our case we needed around std::numeric_limits<int32_t>::max() / 365 years in either direction around 1970 (a number of days since the epoch representable by a 32-bit signed integer). We ended up using a hacked version of https://github.com/HowardHinnant/date, but I'd prefer if boost supported it natively.
If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it.
I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times.
ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense.
So my question is, is there any technical problem in supporting the entire 0 - 9999 range?
If not, then my next question would be, what else would speak against supporting the 0 - 9999 range?
If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400?
My needs would be for the representation type to be user specified, to allow millions of years before and after the epoch.
Cheers, V.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hey — Sorry for the really slow response — work is keeping me extremely busy just at the moment. The 1400-10000 time range is indeed ‘mostly arbitrary’ — let me explain ‘mostly’. So overall, the goal was for dates to fit within 32 bits and span a time range that would accomodate 'most applications’. And it does play into being able to have a matching 64 bit representation of time to cover the range at millisecond resolution. Noting that this decision was made in in the early 2000 there were some other constraints of the time that came into play. One was that Microsoft windows api's used 1470 (or something like that) as an epoch for some date/time api’s — so wanted to be able to support back at least that far. And 10,000 seemed like a nice round end point far enough into the future to support most applications. The actual design goal in date-time v1 was to allow for ‘trivial’ changing of the epoch without re-writing the core code — it’s ‘close’, but it’s more complex than I would like given the original limits of the compilers of the time and my programming abilities. And hence I never really tried to document how it’s done. If you’re really interested in testing the water I could probably provide some minimal support over the next few days. In effect you need to replace a series of typedefs in boost::gregorian that define the date and various auxiliary types — and modify tests if you want to be sure all is working. Going forward for date-time v2, especially with the tools of c++17 I believe it should be possible. I’m slowing working on that now so I’m happy to collect use cases for these scenarios. Anyway, hopefully this explains the mystery :) Best, Jeff
On Jan 9, 2017, at 9:08 AM, Avi Kivity <avi@scylladb.com> wrote:
On 12/22/2016 03:58 PM, Viacheslav Usov wrote:
Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999?
Not an answer, but we also needed dates outside the supported range. In our case we needed around std::numeric_limits<int32_t>::max() / 365 years in either direction around 1970 (a number of days since the epoch representable by a 32-bit signed integer).
We ended up using a hacked version of https://github.com/HowardHinnant/date <https://github.com/HowardHinnant/date>, but I'd prefer if boost supported it natively.
If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it.
I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times.
ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense.
So my question is, is there any technical problem in supporting the entire 0 - 9999 range?
If not, then my next question would be, what else would speak against supporting the 0 - 9999 range?
If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400?
My needs would be for the representation type to be user specified, to allow millions of years before and after the epoch.
Cheers, V.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>
On Tue, Jan 10, 2017 at 7:56 PM, Jeff Garland <jeff@crystalclearsoftware.com
wrote:
The 1400-10000 time range is indeed ‘mostly arbitrary’ — let me explain ‘mostly’. So overall, the goal was for dates to fit within 32 bits and span a time range that would accomodate 'most applications’. And it does play into being able to have a matching 64 bit representation of time to cover the range at millisecond resolution.
Thanks for the explanation, but I fail to understand how this explains 1400. As far as I can tell, the Gregorian calendar types are built around the Julian day number (JDN). 1400 is not in any way special or even near the JDN epoch. The arithmetic in JDN/YMD conversions should work fine for non-negative years. What, indeed, would be affected if greg_year_policy had 0 instead of 1400? Cheers, V.
Maybe nothing if you set to 0 -- it may work fine — nothing fundamental about the algorithms that would break. But I seem to recall there being a potential issue with range of ptime when using a 64 bit implementation going back that far. And honestly these decisions were made so long ago it’s very possible I’m not remembering some other factor that went into the thinking. But I do remember…it’s a ‘mostly arbitrary’ decision. Jeff
On Jan 12, 2017, at 8:15 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
On Tue, Jan 10, 2017 at 7:56 PM, Jeff Garland <jeff@crystalclearsoftware.com <mailto:jeff@crystalclearsoftware.com>> wrote:
The 1400-10000 time range is indeed ‘mostly arbitrary’ — let me explain ‘mostly’. So overall, the goal was for dates to fit within 32 bits and span a time range that would accomodate 'most applications’. And it does play into being able to have a matching 64 bit representation of time to cover the range at millisecond resolution.
Thanks for the explanation, but I fail to understand how this explains 1400. As far as I can tell, the Gregorian calendar types are built around the Julian day number (JDN). 1400 is not in any way special or even near the JDN epoch. The arithmetic in JDN/YMD conversions should work fine for non-negative years.
What, indeed, would be affected if greg_year_policy had 0 instead of 1400?
Cheers, V.
participants (5)
-
alanbirtles2 -
Avi Kivity -
Jeff Garland -
Oswin Krause -
Viacheslav Usov