Time zone confusion and implementation hints

[David Patte]

Hi Robert

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 
different.

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.