Re: [boost] gregorian::date limited to years 1400 - 9999

Subject: Re: [boost] gregorian::date limited to years 1400 - 9999
From: Jeff Garland (jeff_at_[hidden])
Date: 2017-01-10 13:56:22

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_at_[hidden]> 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>