[tz] tabs vs spaces

[Guy Harris]

On May 2, 2013, at 2:59 PM, Tobias Conradi <mail.2012 at tobiasconradi.com> wrote:

> On Thu, May 2, 2013 at 11:00 PM, Guy Harris <guy at alum.mit.edu> wrote:
> 
>> (Note, of course, that Theory is not a document mentioned anywhere in
>> 
>>        http://tools.ietf.org/html/rfc6557
> A lot of files are not mentioned there. Also note, that the RFC is
> labeled "Best Current Practice"
> and "BCP: 175" but diverged from pre-existing Theory and usage:
> 
> "IANA and the tz database - diverging from Theory"
> http://mm.icann.org/pipermail/tz/2011-September/008879.html

Then perhaps it's time to retire Theory in favor of RFC 6557.

>> and not mentioned anywhere on
>> 
>>        http://www.iana.org/time-zones
> two clicks from there and I see the file name, one more click, I see
> the content (using Google Chrome which here allows http and ftp
> browsing)

"You can find it if you dig into the middle of the code directory" is not quite as much of a "mention" as, for example, "the theory behind the database is described in <a href="{some URL}">the Theory file</a>"

>> and not mentioned anywhere in  in any of the man pages or in any of the tzdata files, so it's not a document with any official standing as the ultimate documentation of the time zone database.)
> 
> Where is the "ultimate documentation of the time zone database"?

Perhaps nowhere.  Perhaps a number of places, such as the various man pages for the technical details of the format of time zone data files and of the binary files produced by zic, and RFC 6557 for policies.

>> Well, this benefit
>> 
>>        It lets existing files (which have more than one tab in a row, at least for leading spaces) be read without having to reformat them.
>> 
>> obviously doesn't even apply, because the zone.tab file's existing syntax is different, and if *it* were changed to allow multiple tabs between columns, that would mean that code that read *those* files wouldn't work on the new file.
> 
> I didn't understand that benefit at all.

The benefit of

>>        It lets existing files (which have more than one tab in a row, at least for leading spaces) be read without having to reformat them.


is "if we don't change zic to treat individual white-space characters as column separators, so that

	<TAB>A<TAB><TAB>B

is viewed as three columns, one with the value "A", one blank, and one with the value "B", then we don't change zic in such a way that it gets very confused when it reads the existing time zone rule files, and thus we don't have to change all our files to the new format, *and* we don't have to force anybody who's created their own time zone rule files to change *their* files".

That benefit obviously doesn't apply to the zone.tab file, as, in *that* file, individual white-space characters *are* column separators.  If we were to allow arbitrary sequences of white-space characters to be column separators, we would, at minimum, break the tzselect.ksh script (I tried adding extra tabs and spaces to the America/Los_Angeles entry in that file and running tzselect.ksh, and it did *NOT* find that entry), and might break other code that uses it (the FreeBSD 9 sysinstall program seems to use it, as it doesn't just throw a bunch of zone names at you, and behaves at least somewhat like tzselect.ksh; surprisingly, the PC-BSD 9 configuration programs *don't* use it, they just throw you a bunch of zone names, although I think they at least *did* say "Pacific" for America/Los_Angeles, for the benefit of those of us about 570 km from Los Angeles).

>> The others do apply, but, for better or worse, that's not the format that was chosen, and we're stuck with it.
> 
> OK, that is the current reason. But what might have been the reason
> when zone.tab was established with single tab?

Code to parse it was a bit quicker to whip up with that limitation, given that it was probably not viewed by its creator as being as "core" to the time zone database as the time zone data files?