[tz] [PROPOSED] zic option for including data from a certain year onward

Paul Eggert eggert at cs.ucla.edu
Fri Mar 15 16:45:48 UTC 2019


On 3/14/19 7:13 PM, Christopher Wong wrote:
> I rebased to the latest and did some testing. I didn't got any more segmentation fault, so that is fixed.
>
> However, I encountered something else related to the truncation. I compiled with the following range 1977-1984 :
>
> ./zic -L /dev/null   -d $ZONEINFO  -r @220924800/@441763200  ${tz}
>
> ./zdump -v $ZONEINFO/Australia/Perth
>
> The result I got was:
>
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  -9223372036854775808 = NULL
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  -9223372036854689408 = NULL
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  Sat Oct 29 17:59:59 1983 UT = Sun Oct 30 01:59:59 1983 AWST isdst=0 gmtoff=28800
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  Sat Oct 29 18:00:00 1983 UT = Sun Oct 30 03:00:00 1983 AWDT isdst=1 gmtoff=32400
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  9223372036854689407 = NULL
> /home/christwo/dists/tz/test_zic_github/Australia/Perth  9223372036854775807 = NULL
>
> I was expecting many dates before 1983.

But the range you specified (@220924800/@441763200) is from 1977-01-01
00:00 UTC through 1984-01-01 00:00 UTC. Perth saw only one transition
during that period, namely, the 1983-10-29 transition listed above. So
this zdump output is correct, no?

zdump by design does not output no-op transitions like the transitions
at 220924800 and at 441763200 in that TZif file.

> I extracted the timestamps below, should the last transition be 1s after range end?
>
> 0d 2b 0b 80     220924800	Saturday, January 1, 1977 0:00:00 
> 1a 01 62 a0	    436298400	Saturday, October 29, 1983 18:00:00 
> 1a 54 c5 81	    441763201	Sunday, January 1, 1984 0:00:01

This was due to an off-by-one discrepancy between the zic -r syntax and
the RFC 8536 truncation rules. 'zic -r /@T' meant to truncate *after*
time T, whereas RFC 8536 means to truncate *before* time T (this is as
per RFC 7808 section 3.9). Thanks for pointing out this off-by-one
discrepancy. It's better for zic to be consistent with the RFCs, so I
installed the attached patch to remove the discrepancy, and also to
check more carefully for overflow and for empty ranges.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-zic-r-T-is-now-exclusive-not-inclusive.patch
Type: text/x-patch
Size: 3131 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20190315/9f6f3511/0001-zic-r-T-is-now-exclusive-not-inclusive.patch>


More information about the tz mailing list