Possible corrections?

Ken Pizzini tz. at explicate.org
Wed Jul 5 20:43:03 UTC 2006

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

>  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

>   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

More information about the tz mailing list