<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 July 2015 at 19:49, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Jon Skeet wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm looking at the output of zic for each zone, and almost all zones start<br>
with a "transition" for some timestamp in the long distant past - including<br>
fixed zones such as UTC and Etc/*.<br>
</blockquote>
<br></span>
Can you give more details about the problem, for UTC and PST8PDT say?<br>
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.<br></blockquote><div><br></div><div>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) <i>do</i> assume standard time before the first transition. I'm currently using the zic code from 2015e, btw.</div><div><br></div><div>(Note: I always look at the second set of values in the file, i.e. the 64-bit ones.)</div><div><br></div><div>When processing UTC the first and only transition is at -576460752303423488 - the big bang value you noted later.</div><div>When processing PST8PDT the first transition is -1633269600, i.e. in 1918.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
<br>
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.<br></blockquote><div><br></div><div>In terms of <i>input</i>, 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 <i>only</i> 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.</div><div><br></div><div>So <i>if</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>Jon</div><div><br></div><div><br></div><div><br></div></div><br></div></div>