[tz] zdump bug in Asia/Singapore

Tim Parenti tim at timtimeonline.com
Tue Sep 9 14:51:46 UTC 2014


Unfortunately, it seems your example doesn't match observed behavior.
Consider:

Zone    Test/Transition1970 2:00    -   XST 1970 Jan  1  0:00u
            3:00    -   YST

https://github.com/eggert/tz/commit/8973320770f676c249229c5c4ca402057e7ec098
says "a *loyear* of 1970 includes a transition occurring at the very start
of 1970 but a *hiyear* of 1970 excludes the transition."  The opposite
behavior is observed:

$ ./zdump.exe -Vc 1969,1970 Test/Transition1970
Test/Transition1970  Wed Dec 31 23:59:59 1969 UT = Thu Jan  1 01:59:59 1970
YST isdst=0
Test/Transition1970  Thu Jan  1 00:00:00 1970 UT = Thu Jan  1 03:00:00 1970
YST isdst=0
$ ./zdump.exe -Vc 1970,1971 Test/Transition1970

If the transition is one second later, the behavior matches the
description.  Currently zdump is inclusive then exclusive at a year-level,
but exclusive then inclusive at a second-level.  This is why I described
the current behavior as "inclusive of the start year except exclusive of
its first instant, and exclusive of the end year except inclusive of its
first instant".  Since this wording is quite awkward, it may be simpler to
adjust the code to match the description you provided.

I also just noticed, above, that zdump returns "YST" for both timepoints in
the transition above, when this should be a transition from XST to YST.  It
seems that's another (related?) issue.

--
Tim Parenti

On 8 September 2014 15:28, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 09/08/2014 11:55 AM, Tim Parenti wrote:
>
>> we should at least include that in the docs
>>
>
> Thanks, good point, and attached is a proposed patch to do that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140909/74de9224/attachment.html>


More information about the tz mailing list