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 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::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

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 wrote:

On Tue, Jan 10, 2017 at 7:56 PM, Jeff Garland 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.