Yes, it would be a help to provide the documentation note. As one of the new 'independent' TZ database users (actually developer), I struggled with the format, until I found the zic doc by accident. I didn't have a linux or Unix system available for a resource, so was trying to use the TZ datastore and convert it for use with MS ASP.Net. The tab formatting of the file was not consistent, and I remedied that by parsing it with custom programs that converted it. I don't really have a preference for which operating system is a developer or user's choice, but find it really handy to opt for some kind of datastore structure that is easily translated from one system to another. It's just a nice feature to provide. In this case, the TZ datastore is the de facto standard for this type of information, not only for Unix /Linux systems but becoming a standard reference tool for other systems as well, like it or not. Now, to be honest all systems have their issues, so it's not really a question of which O/S is best, but rather how system administrators, developers, and users can best be helped by standarding on common refernce information, such as, timezones. Not an easy task since globally there is no single historical authoritive source. However, since the TZ datastore is the closest I've found, it's the one I'll use, rather than creating another competing version. The only thing I'm doing is making it easier to implement and update for MS systems. If only MS would see fit to use a similar tact, then maybe we could get past the silly issues of converting it. All in all, no matter what doc is available, we still depend on developers to intpreted it correctly. The only critique I have is the somewhat confusing aspect of the use of the AT field: AT Gives the time of day at which the rule takes effect. Recognized forms include: 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds - equivalent to 0 where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter w if the given time is local "wall clock" time, s if the given time is local "standard" time, or u (or g or z) if the given time is universal time; in the absence of an indicator, wall clock time is assumed. It would make lessen the confusion or how to translate this field if the data were always presented in wall clock time, for us independent types, anyway. Just my 2 cents. -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Monday, July 03, 2006 5:30 PM To: tz@lecserver.nci.nih.gov Subject: Re: Possible corrections? Oscar van Vlijmen <ovv@hetnet.nl> writes:
Sorry for my annoying remarks, but the independent TZ database users keep coming and they apparently get easily confused by the current structure or markup of the data files.
In this particular case, the user had not read the manual, and didn't even know one existed. That would be a problem no matter what format we had chosen. Perhaps we could forestall future questions like this by starting each data file with a line saying "The format of this file is described in <http://www.twinsun.com/man/zic.8.html>." or something like that. Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s), and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and delete all copies of the original message.
On Wed, Jul 05, 2006 at 10:59:43AM -0500, Phillip Guerra wrote:
Yes, it would be a help to provide the documentation note. As one of the new 'independent' TZ database users (actually developer), I struggled with the format, until I found the zic doc by accident. I didn't have a linux or Unix system available for a resource, so was trying to use the TZ datastore and convert it for use with MS ASP.Net. The tab formatting of the file was not consistent, and I remedied that by parsing it with custom programs that converted it.
It sounds like what is missing is documentation (presumably in the tzdata file comments?) that independent developers are encouraged to download the reference tzcode tarball. This way they get both the zic.8.txt documentation of the zone file format, and the reference implementation of zic.c to use both as a starting point for their own conversion software and to clarify any ambiguities in the zic.8 document (ideally, in this latter case, with a bug report about the ambiguity sent to the TZ list).
I don't really have a preference for which operating system is a developer or user's choice,
While the heritage is Unix, the tzcode source is mostly portable ANSI C (ignoring the code for the "date" target, which has highly system-specific code, and the tendency to use POSIX I/O even when stdio would be fine). The bit that parses the tzdata files is highly system agnostic.
but find it really handy to opt for some kind of datastore structure that is easily translated from one system to another. It's just a nice feature to provide. In this case, the TZ datastore is the de facto standard for this type of information, not only for Unix /Linux systems but becoming a standard reference tool for other systems as well, like it or not.
The tzdata source format is intended for easy editing by humans, not interchange between machines; if one is interested in machine-oriented data, the zic output is probably a better first choice, though creating a third format that is more database-like (transformed from tzdata by a zic-like tool) might be a reasonable idea. But the primary format really needs to be oriented for the ease of human editing and proofreading.
The only critique I have is the somewhat confusing aspect of the use of the AT field: [...] and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter w if the given time is local "wall clock" time, s if the given time is local "standard" time, or u (or g or z) if the given time is universal time; in the absence of an indicator, wall clock time is assumed.
It would make lessen the confusion or how to translate this field if the data were always presented in wall clock time, for us independent types, anyway.
Again, the source file is oriented towards human editing. The suffixes are provided to allow the tzdata entry to mimic the official legislation or decrees, to allow easier eyeball cross-checking. --Ken Pizzini
participants (2)
-
Ken Pizzini -
Phillip Guerra