<div dir="ltr"><div>Thanks for the message.<br></div><div><br></div><div>Yes, you were correct in thinking that </div><div><i>If the <b>FORMAT</b> field contains either a "%s" or a '/' then the <b>RULES</b> field must contain a named rule.</i><br></div><div> was a trial rule of my own invention for my own parser implementation. I saw a pattern in the historic data and was curious as to whether it applied everywhere. I have now modified my checks so that all files pass.</div><div><br></div><div>To be clear, I am not suggesting that the zic compiler mishandles any old data files. Neither am I suggesting that there are any errors in the zic documentation.</div><div>When I was referring to data being at slight variance to the documentation, the documentation I was referring to was:</div><div><a href="https://data.iana.org/time-zones/tz-link.html">https://data.iana.org/time-zones/tz-link.html</a> and <a href="https://data.iana.org/time-zones/tz-how-to.html">https://data.iana.org/time-zones/tz-how-to.html</a></div><div>I now recognise that I would have been better off using the zic documentation as my primary source.</div><div><br></div><div>Nonetheless, here are a few things I have found:</div><div><br></div><div>1. tz_link.html  states that:</div><div><i>Sources for the tz database are UTF-8 text files... </i><br></div><div>Some of the comments in some of the old files contain non UTF-8 single byte representations of accented letters. Since such occurrences are in the comments this will not affect anything.</div><div><br></div><div>2. The  tz_how-to.html states that:</div><div><i>Prior to the 2020b release, it was called the TYPE field, though it was never used in the main data ...</i></div><div>However, some of the old data in <a href="https://data.iana.org/time-zones/releases/">https://data.iana.org/time-zones/releases/</a> contains "even" and "odd" to account for the Adeleide festival. (I got round this by excluding the versions of the Australia/Adeleide exhibiting "even" and "odd".)</div><div><br></div><div>3. The  tz_how-to.html states that:</div><div><i>The FORMAT column specifies the usual abbreviation of the time zone name. It can have one of three forms:<br>a string of three or more characters that are either ASCII alphanumerics, “+”, or “-”, in which case that’s the abbreviation ...</i><br></div><div>I had to allow an underscore and space to allow all the files to pass. In the case of St. Helena I also had  to allow a '?' as the first character. Further, I had to allow an abbreviation in a '/' separated format to be only two characters.(I recognise that this is not technically in violation of the statement above.)</div><div><br></div><div>4. I can see that some of the older files use a '?' where the more modern files use '%s'. This is not mentioned in the tz_how-to.html documentation, I recognise that putting such obscurities in the document may not be a good idea.</div><div><br></div><div>As you can see these are all very minor things. I appreciate your quick responses.</div><div><br></div><div>Regards</div><div><br></div><div>Nick</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 May 2022 at 20:20, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/13/22 09:35, Tim Parenti via tz wrote:<br>
<br>
> I'm not sure where your "must contain a named rule" quote is coming from<br>
<br>
I imagine this was a style rule of Nick's invention. Violating the rule <br>
might issue a warning but it shouldn't be a fatal error, as the 'asia' <br>
file was correct as-is.<br>
<br>
> in this case the "rule" is not named, *per se*, but is rather a constant<br>
> 1:00.  The relevant thing is that the RULES field is not "-".<br>
<br>
Or more precisely it's that the RULES column is neither "-", nor a <br>
suffixless zero offset, nor an offset with an "s" suffix. We don't use <br>
any of these more-obscure features in TZDB data but they're in the .zi <br>
format.<br>
<br>
Since TZDB consistently avoids '/' in the many other places where this <br>
situation arises, it should avoid '/' here for stylistic consistency. So <br>
I installed the attached proposed patches. The 1st patch omits the '/' <br>
in question; the 2nd documents that STDOFF columns don't have suffixes <br>
(this wasn't clear in the man page, and I discovered this while looking <br>
into the 3rd patch), and the 3rd adds a style check for this.<br>
<br>
None of these patches affect the TZif output files.</blockquote></div>