"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:
While standard time wasn't introduced before 1800 anywhere, there are earlier time oddities (such as swiches from the Julian to the Gregorian calendar, switches to the Julian calendar, skipping of the year zero, and leap year gyrations). While the current time zone package doesn't try to handle these oddities, other packages might.
I don't know of any such package, but even if there were such a thing, zdump wouldn't work with it. For example, it would get hopelessly confused (loop or crash or report wrong data, I don't know what) if given an implementation that accurately implemented the calendar used in the English colonies in America before 1750, where the year began on March 25. Or the Byzantine calendar, where the year began on September 1. Or the Japanese calendar, where the year numbers restart at 1 every time there is a new emperor. One other data point: in all of these other systems, leap years are not even a multiple of 4, much less the 4/100/400 Gregorian rule that zdump assumes. There's no real need to go back before 1800 (and expose all those zdump "bugs" :-), until and unless we change zdump to support calendars other than the proleptic Gregorian calendar ("proleptic" because it assumes the Gregorian calendar is valid for all time). On the other hand, I can think of four transitions that I would like zdump to report, for 64-bit hosts. These transitions will test bugs in the implementation of the proleptic Gregorian calendar. First is the transition between localtime returning NULL (because time_t is too negative) and localtime working (because time_t is barely in range). Similarly for the maximum time_t that localtime works on. And two more transitions for gmtime. These boundaries should be findable fairly easily, and if you're interested I can try to find some time to write up the code.