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