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