[tz] Lack of "initial" transitions for some zones

[Jon Skeet]

On 21 July 2015 at 19:49, Paul Eggert <eggert at cs.ucla.edu> wrote:

> Jon Skeet wrote:
>
>> I'm looking at the output of zic for each zone, and almost all zones start
>> with a "transition" for some timestamp in the long distant past -
>> including
>> fixed zones such as UTC and Etc/*.
>>
>
> Can you give more details about the problem, for UTC and PST8PDT say?
> It surprises me that the long-ago timestamp is issued for some output
> files but not others; I'm not sure why that would be.
>

Well, I'm not sure I'd go so far as to say "problem" - other than for my
validation efforts, where other APIs (including Noda Time) *do* assume
standard time before the first transition. I'm currently using the zic code
from 2015e, btw.

(Note: I always look at the second set of values in the file, i.e. the
64-bit ones.)

When processing UTC the first and only transition is at -576460752303423488
- the big bang value you noted later.
When processing PST8PDT the first transition is -1633269600, i.e. in 1918.

The zic.8 documentation does not uniquely specify the output file, given
> the input: multiple output files can correctly implement the input.  So
> it's possible that you haven't found a bug, but still, it is curious.
>
> Possibly this is due to the transition change introduced in 2014c (see
> commit 7fb077a9ff67dab22b9a23f64f65f85d59cf593e) and updated by the Big
> Bang change in 2014d.  Are the long-ago transitions equal to -2**59 ==
> 0xf800000000000000 == -576460752303423488?  If so, that's most likely
> what's going on.
>

In terms of *input*, I think it's reasonably understandable - most zones
start with a zone line with a "-" for the rule name. These 8 rules don't -
the *only* line for each of those zones is one which specifies a rule. The
fixed-offset zones (e.g. EST, MST, HST) only have a single line each, but
that line doesn't specify a rule - so it goes back to the start of time.

So *if* we wanted to change anything (and it's unclear whether we should)
the simplest option would probably be to give an extra zone line for each
of those zones, specifying standard time until the first transition.

Whatever we do, I'll need to think about what the tzvalidate format should
say about it, if anything - because it won't change the retrospective data
either way, and I'm not trying to suggest that implementations change their
behaviour, either.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150721/7448d416/attachment.html>