Html-ize the tz database?

[Oscar van Vlijmen]

Gwillim Law wrote:
> I've just now posted a few sample Web pages to display data from the tz
> database in a more accessible format.
Very nice effort! This information is excellent for human readers. I
especially like the page "State and Province Links" (ls.html) with its many
relevant links.

> Is it
> feasible to maintain a Web site like this in synch with the tz database?
That depends. Who's gonna maintain this web site for as long as the tz-info
will be maintained? It involves a lot of work which cannot be programmed.
For instance, checking the existence of links can be automated, but finding
new ones not.

Consistent data
----------------
One job should be done soon, I would like to suggest.
That's to improve the consistency of the tz data within its format.
If the tz data files were extremely consistent, programmers of non-unix
applications had less manual labor to do, _much_ less, as I experienced
myself for my Macintosh HyperCard application.

Two examples:
1. The zone.tab information (land code, coordinates) should be integrated
into the tz data files.
2. In most cases the Rule and Zone fields are separated by a tab, but
sometimes by a space run and sometimes by nothing, just an absolute
character position.
This gave me severe headaches transporting the data to my application.
Another issue is that many useful information bits are commented out (#) and
reside at rather random locations.

It has been proposed to xml-ize the tz data files.
This would improve the transportability, but it would degrade the human
readability.
Although Garrett Wollman said on Apr. 18 2000:
"And there is no inherent virtue in XML....."
it would make especially a difference if there were a concurrent web site
with tz data like Gwillim Law's proposal.
The April 2000 "Time Zone Issues" thread discussed many pros and cons around
xml.
The "format of tz database" thread discussed the VTIMEZONE format.

I think there is a 'market' for extremely consistent and transportable (i.e.
script readable) tz data. But html? Excellent for humans, but I would like
to address the issue application transportability. So XML?

Proposals:

1. Keep for the moment the current tz data format, but clean it up: exactly
1 tab as data field separator, no spaces, always 1 tab.

2. Integrate zone.tab info in special comments, for instance beginning with
#%, if necessary separated by tab fields.

3. Replace recurring information which is now # commented to _special_
commented lines.

In this manner current Unix tz-applications can still use the tz data, but
the data is much better transportable to other applications.
Complex comments are very productive: take for example the OPI
comments/directives in PostScript code.

Regards,

Oscar van Vlijmen
2001-03-02