[tz] tzfiles contain Unix epoch for the first transition time

random832 at fastmail.us random832 at fastmail.us
Sat Aug 15 22:14:59 UTC 2015


On Fri, Aug 14, 2015, at 21:36, Robert Elz wrote:
> I have no idea if that -7537 is 7537 BC or 7538 BC (ie: whether it is
> assumed that there was a year 0 or not). 

It is 7538 BC. The same value works on OSX, and -62150000000 gives the
year 0000. This is specified by ISO 8601, but neither the C standard nor
(as far as I know) POSIX provides any guidance other than saying the
meaning of years less than 1 is unspecified.

I do notice that if I attempt to enter the actual big bang time, I get
the error message "date: localtime: Value too large to be stored in data
type" - the actual limit being run into seems to be a 32-bit value for
tm_year (the largest negative value it can represent is a year of
2147481748: -2**31 + 1900). Interestingly, strftime apparently has no
trouble formatting a year of 2147485547 (2**31+1899) despite that being
beyond the 32-bit limit.

> I suspect that this all happens
> just by accident, and no-one really ever considered the possibility of
> negative years - it is only since time_t's became 64 bits (the last few
> years) that it even became possible, before then the range was about 
> 1901..2038)
> 
> Simply claiming that years before year 1 don't exist avoids both
> problems, so it is kind of an elegant solution.

Artificially limiting the year range also allows you to use a fixed-size
broken-down time format (python datetime uses a 16-bit year) or a
floating-point format (MS Excel and therefore COM use a floating-point
format measured in days) - both limit the year to 1 through 9999 and not
having to contend with different formats having different real limits.


More information about the tz mailing list