Thanks for the explanations, that helps. Could the explanation of transitions and the default for LETTER/S before the first year be added to zic.8.txt?<br><br>As to UNTIL, it isn't just a confusion. The documentation says:
<br><pre> Input lines are made up of fields. Fields are separated<br> from one another by any number of white space characters.<br> Leading and trailing white space on input lines is ignored.<br></pre>Thus saying that UNTIL is a single field with interior spaces contradicts this (and is also clumsier to parse and harder to explain).
<br><br>Mark<br><br><div><span class="gmail_quote">On 9/27/06, <b class="gmail_sendername">Ken Pizzini</b> <<a href="mailto:tz.@explicate.org">tz.@explicate.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Sep 27, 2006 at 02:37:58PM -0700, Mark Davis wrote:<br>> I share your confusion. If Paul (Eggert's) description is right, then I have<br>> to ignore the TO field in some circumstances which are entirely unclear to
<br>> me. I would much rather see the TO field corrected. That is, if TO=1942 is<br>> ignored, and 1945 is the real date, then the line should be corrected to<br>> TO=1945.<br><br>The key to understanding is that the rules describe a list of *transitions*.
<br><br>After a transition, the described effect on zone offset and abbreviation<br>*remain* in effect until the next transition. The "TO" part of a rule is<br>used to enable a shorthand for a _recurring_ transition, such as "first
<br>Tuesday of February", for all years within the range. If "to" is<br>"only", then the *transition* being documented is a singleton, but<br>the transitioned-into offset/abbreviation remains in effect until the
<br>_next_ transition, no matter how far in the future.<br><br><br>> There are other failures in the parsing. My error messages are:<br>...<br>> I looked into why this is happening, and found:<br>><br>> Zone Europe/Amsterdam 0:19:32 - LMT 1835
<br>> 0:19:32 Neth %s 1937 Jul 1<br><br>> But the first LETTER/S defined by Neth is in 1916, so during the range from<br>> 1835 to 1916 this is undefined. If the LETTER/S are magically also defined
<br>> *before* the first FROM, that should be described in the specification.<br><br>Yes, this is a failure of the documentation. If a Zone refers to a time<br>within a Rule that is before the first transition mentioned for that rule,
<br>then the _oldest_standard_time_ "Letter/s" is used. In this case, AMT.<br><br><br><br>> BTW, the documentation was a first a bit confusing to me, since it says that<br>> fields are delimited by spaces, and lists a single Zone UNTIL field.
<br>> However, if you look carefully at the documentation, there are really 4<br>> fields:<br>><br>> UNTIL_YEAR UNTIL_IN UNTIL_ON UNTIL_AT<br>><br>> which are optional [but only in "truncation" from the end: that is, it
<br>> corresponds to the (Perl) regex (UNTIL_YEAR (UNTIL_IN (UNTIL_ON<br>> (UNTIL_AT)?)?)?)?].<br>><br>> I'm not the only one to have initially made this mistake: the proposed XML<br>> format for the TZ database makes the same mistake.
<br><br>Confusing: granted. Whether "Until" is one or multiple fields is a<br>matter of interpretation. The _traditional_ understanding is that it<br>is a *single* "timestamp field" which may happen to have spaces within
<br>it. BTW the subfields aren't "YEAR IN ON AT", but "YEAR MONTH DAY TIME".<br><br>In this regard, a recent addition to the tzcode tarball is zoneinfo2tdf.pl,<br>which translates the more free-with-spaces zone tzdata into a form which
<br>strictly uses a single tab between fields. This may make life easier<br>for some by simplifying their parser's requirements. (Or not.)<br><br> --Ken Pizzini<br></blockquote></div><br>