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.