Time zone confusion and implementation hints

Yves Goergen nospam.list at unclassified.de
Fri Jul 2 14:18:05 UTC 2010


[This part of my reply was composed after reading several replies:]

When a zone defines that a rule set is valid until before 1990 Sep 3 at
2:00w or 2:00s, how exactly am I supposed to find out when that is?
Either way, the exact time of that switch depends on the UTC and save
offsets around that point in time, ie the rule set (Zone definition)
and/or the relevant rule in the moment before and/or after that time.
Both base UTC offset and additional save offset may change in that
moment. Which of them shall be applied, the previous or the next
interval's values?

Is there some higher-level algorithm available of how that works? Right
now I can't even think of a way to do it 'manually' by reading the text
files and calculating stuff in my brain. How should I tell a stupid
computer what to do?

The ZoneInfo code (C#) doesn't even care about it and produces errors.
The (now dead?) (full-blown) PublicDomain library (C#) seems to be
restricted to two transition times per year (like Windows) and also
doesn't seem to care very well about the exact moment of change. I don't
understand the cryptic original code (C) of the tz distribution.
Android's implementation (Java) in org.apache.harmony seems too short to
be complete.

The tz format description doesn't explain how to use the data
programmatically. So right now I understand the data format but don't
see how it can be used for real computing.

[This part of my reply was composed after reading Guy Harris' reply:]

I was totally unaware that zic does all that. It sounds interesting
though. I think I could find an algorithm for UTC to local conversion
with all transition times in UTC. The reverse function however would
still be educated try and error.

I can't compile zic.c with Visual Studio 2008, some unixoid libraries
are missing and I don't think I have them. Using the Makefile doesn't
look more promising. So I need to implement zic's function - or
something similar - myself.

The format description of the compiled tzfile is very verbose which
makes it hard to get an overview of what is stored where. I have
attached an incomplete pseudo-code description of what I think it might
look like. Anyway it would just be an aid in reverse-analysing the zic
code. (I find it helpful to start from the output so I won't see
anything I don't need for that.)

But now I'm wondering about where the annual rules are gone. The
compiled tzfile only seems to contain fixed transition times. Anything
that's not stored literally in the file is unknown. Are all dates
between 0001-01-01 and 9999-12-31 stored in the file? Or just between
1970-01-01 and 2038-xx-xx, or maybe even in a configurable time span?
Doesn't that produce masses of redundant data and limit the usage of the
database?

-- 
Yves Goergen "LonelyPixel" <nospam.list at unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tzfile-structure.txt
Url: http://mm.icann.org/pipermail/tz/attachments/20100702/474d2b4e/tzfile-structure-0001.txt 


More information about the tz mailing list