Re: calendar gets wrong end for Daylight Savings Time

[Glenn Morris]

James Cloos wrote:

> zdump(8) gives a textual dump of a given timezone when passed the -v
> flag.  If that is available on all platforms it should do.

Oh thanks, I did not know about zdump. Can anyone confirm if
it/something equivalent exists on Windows?

> As an example, this is what it outputs for America/Phoenix:
[...]
> | America/Phoenix  Sun Apr 30 08:59:59 1967 UTC = Sun Apr 30 01:59:59 1967 
> MST isdst=0
> | America/Phoenix  Sun Apr 30 09:00:00 1967 UTC = Sun Apr 30 03:00:00 1967 
> MDT isdst=1
> | America/Phoenix  Sun Oct 29 07:59:59 1967 UTC = Sun Oct 29 01:59:59 1967 
> MDT isdst=1
> | America/Phoenix  Sun Oct 29 08:00:00 1967 UTC = Sun Oct 29 01:00:00 1967 
> MST isdst=0
> | America/Phoenix  Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 20:14:07 2038 
> MST isdst=0
> | America/Phoenix  Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 20:14:07 2038 
> MST isdst=0
> `----

So what in that output tells me that the DST transition date changes
in 2007?

On a 64-bit system, the last two entries in the above output are
replaced by the less enlightening:

America/Phoenix  9223372036854689407 = NULL
America/Phoenix  9223372036854775807 = NULL


Since I have a method that (I think) should work well on all platforms
in the style that the calendar currently uses, I'm tempted to install
the patch I already have, and file switching to this method as a TODO
item for some future date.