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