<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 July 2015 at 23:01, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</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="">On Jul 18, 2015, at 3:40 PM, Jon Skeet <<a href="mailto:skeet@pobox.com">skeet@pobox.com</a>> wrote:<br>
><br>
> Next update: I've improved the zdump-based generation of the data, and put the data in the current format for all the tz data releases I can find (from 1996 onwards) at <a href="http://nodatime.org/tzvalidate/" rel="noreferrer" target="_blank">http://nodatime.org/tzvalidate/</a><br>
<br>
</span>I’ve generated a version of tzdata2015e-tzvalidate.txt.zip from my code here:<br>
<br>
<a href="http://howardhinnant.github.io/tzdata2015e-tzvalidate.txt.zip" rel="noreferrer" target="_blank">http://howardhinnant.github.io/tzdata2015e-tzvalidate.txt.zip</a></blockquote><div><br></div><div>I saw your earlier message and hoped you were reading this thread too. Supporting code such as yours is precisely the motivation for this endeavour.</div><div> </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">
There are appear to be two kinds of differences:<br>
<br>
1. I appear to start earlier than you, for example I have:<br>
<br>
Africa/Algiers<br>
1891-03-14T23:48:48Z +00:09:21 standard PMT<br>
<br>
and you do not.<br></blockquote><div><br></div><div>That much is simple to explain - the format I'm currently generating explicitly starts in 1905 and ends in 2035. The 1905 part was due to an earlier version of zdump I was using was limited to 1900.</div><div>As per Paul's messages earlier in the thread, eventually we'll want to expose more data - although it's not clear how <i>late</i> it's worth going. (I doubt that it's worth extending beyond 2100 for example.)</div><div> </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">
2. This one has me more concerned: When a zone specifies a rule/date combination and the date falls of the beginning of the rule table, I assume a “” variable part, where you appear to assume a “S” variable part. For example, I have:<br>
<br>
America/Barbados<br>
1924-01-01T03:58:29Z -03:58:29 standard BMT<br>
1932-01-01T03:58:29Z -04:00:00 standard AT<br>
1977-06-12T06:00:00Z -03:00:00 daylight ADT<br>
<br>
And you have:<br>
<br>
America/Barbados<br>
1924-01-01T03:58:29Z -03:58:29 standard BMT<br>
1932-01-01T03:58:29Z -04:00:00 standard AST<br>
1977-06-12T06:00:00Z -03:00:00 daylight ADT<br></blockquote><div><br></div><div>Just to be clear, this isn't "me" so much as "zic and then zdump". It happens that Noda Time (which is more "my" code) does the same thing though :)</div><div> </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 America/Barbados Zone switches to the Barb Rule on 1932-01-01T03:58:29Z, using the format A%sT. But the first Barb Rule is 1977-06-12 2:00. I looked for documentation for what is supposed to happen in a situation like this, but didn’t find anything.</blockquote><div><br></div><div>I think AST makes sense here (as it's standard time) but I agree that it's not clearly documented.</div><div><br></div><div>In Noda Time, if I don't find a rule leading "into" the transition period, I take the name of the first rule with no daylight savings.</div><div>See <a href="https://github.com/nodatime/nodatime/blob/20d57967e04f1b57a10c00910f337a1c3caf7522/src/NodaTime.TzdbCompiler/Tzdb/DateTimeZoneBuilder.cs#L127">https://github.com/nodatime/nodatime/blob/20d57967e04f1b57a10c00910f337a1c3caf7522/src/NodaTime.TzdbCompiler/Tzdb/DateTimeZoneBuilder.cs#L127</a> for the code involved.</div><div><br></div><div>zic appears to implement equivalent behaviour, although I wouldn't like to pin down where.</div><div><br></div><div>I'd be interested in seeing whether your understanding of the data in natural language ties in with the comments expressed in DateTimeZoneBuilder at the link above, by the way.</div><div><br></div><div>Jon</div><div><br></div></div></div></div>