zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)

[Paul Eggert]

"Olson, Arthur David \(NIH/NCI\) [E]" <olsona at 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.