Time zone confusion and implementation hints

Robert Elz kre at munnari.OZ.AU
Tue Jul 6 21:06:03 UTC 2010

    Date:        Tue, 06 Jul 2010 21:58:29 +0200
    From:        Yves Goergen <nospam.list at unclassified.de>
    Message-ID:  <4C338AE5.7010309 at unclassified.de>

  | What does zic use links for? Does it link zone aliases?

Yes, and the default timezone.

  | I think I won't need them in my calendar application, do I?

Probably not, they're mostly for backwards compatibility (old names of
zones that have been renamed).

  | Could I disable creating duplicate files (or linking them)?

So you can avoid using NTFS, yes, just have link return -1, as I suggested
(in mail I sent after you sent this one...) and you'll get symlinks instead.
I think those will work on FAT - trying to make them go away isn't worth the
bother (you can always remove anything that you don't need later).

With 64 bit times, attempting to write the complete rand of years to the file
would be absurd, so we no longer do that - the file still retains the
complete range of 32 bit time_t years (1970-2038) as that's what it used to
be like, and old systems expect to find that data.

But for more modern systems, we recognise that times in the future (beyond
some near future year, usually this year, occasionally next year, and for
now at least, all well before 2038) are obtained by guessing from a rule.
Historical times have all kinds of anomalies, and future times will as
well - but we don't know what the future ones are yet...   So, once we
get out beyond where we have any recorded data, we just use the rule
(embedded in the tzfile) to encode any future time.   It will be wrong in
many cases, but it is as good as is possible.

So, use the data to deal with all the weirdness until the data runs out,
then just use the rule.   This is the comment from tzfile.h that
describes all of this ...

** If tzh_version is '2' or greater, the above is followed by a second instance
** of tzhead and a second instance of the data in which each coded transition
** time uses 8 rather than 4 chars,
** then a POSIX-TZ-environment-variable-style string for use in handling
** instants after the last transition time stored in the file
** (with nothing between the newlines if there is no POSIX representation for
** such instants).

The "POSIX-TZ-environment-variable-style string" is the rule.


More information about the tz mailing list