Time zone confusion and implementation hints
dpatte at relativedata.com
Tue Jul 6 04:02:02 UTC 2010
I enjoyed reading your rant, and I agree with a lot that you say, but
not all. Certainly, the source file format is something that one would
think that all users of the data should have the chance to comment
about. I'm sure there are many people that would prefer there never be
any changes at all, and others that could provide novel suggestions for
enhancements. I would hope that all suggestions about the data, from all
users, would be at least entertained. The needs of all users are
different, and the prefered format for their needs will therefore be
That said, of course, its up to the maintainers, knowing their users, to
decide in which format the data should be released, and if that doesnt
conform with the wishes of some of the users, then of course, its up to
those users to find other solutions.
In our case, our requirements where that we could provide updated
timezone information to our users within 24 hours of being aware of
them. Since we are not in charge of generating the original data, we are
dependant on its releases for updates, as we all are. As well, since we
do not maintain zic, we are dependant upon any changes that may need to
be applied to it as well.
Our solution was to write our own parser to extract the data we needed
directly from the tar.gz, and put it into a format that was most
appropriate for our own use, bypassing zic altogether. This removes one
level of dependancy, and also gets the data into our preferred format
immediately. When there is a new tar.gz released, our users can have
updated data in their systems automatically by an automated ftp.
The basis of our current requirements, is to provide time and date
information for long-range (past and future) research . Our parsers are
used in astronomy products, archo-astronomy products, as well as for
genealogy and other historical research. Our time & date conversions
reach back and look forward tens of thousands of years, and can generate
the solar, mean and 'zone' time for any date over a 100,000 year span,
as well as matching against dates in other calendars.
Though its true that no one was wondering about daylight saving and zone
offsets 10000 years ago, the dates we compute for 10000 years ago, give
users a 'feel' for the time of an event that happened that long ago.
Most people don't know the difference between apparent time and mean
time, but saying that an event likely happend near 6PM EST June 1st
8000BC is something that most people can relate to. More importantly,
for more recent historical research, knowing when a region generally
went from solar time to local mean time, then to standard time is very
useful for pinning down the accuracy and synchronicity of recorded
historical events - such as eclipses.
Im sure the tz database was never originally intended for this purpose,
but no doubt there are others on this list that use what they can from
tz, then augment it with data and algorithms from other sources. If we
suggest changes to tz to make things easier for us, without interfering
with the needs of current users, its because the data is now being used
far beyond its originally intended purpose.
As for my thoughts about changing the actual format for my own needs, i
have made a few suggestions, but think most of my ideas would probably
cause more grief to others than the advantage they might gain me, so
most of my suggestions have remained unmentioned and are handled instead
in our parsers.
More information about the tz