|
Boost : |
Subject: Re: [boost] gregorian::date limited to years 1400 - 9999
From: Avi Kivity (avi_at_[hidden])
Date: 2017-01-09 11:08:49
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk