timezones compatible with POSIX? [forwarded with permisison]

Robert Elz kre at munnari.OZ.AU
Sat May 7 05:15:40 UTC 1994

    > From: mommy <peggyd at sco.COM>
    > To: ado at elsie.nci.nih.gov
    > Date: Fri, 6 May 94 10:59:55 PDT
    > Message-Id:  <9405061059.aa21366 at ping.sco.com>
    > I work at the Santa Cruz Operation, a company that makes
    > UNIX.  I am designing and implementing the part of our
    > installation that sets time zones.  A search for complete,
    > thorough timezone information led me to your anonymous ftp
    > site, and I would like to use the information that you make
    > available, if possible.

Great - the more commercial systems that implement sane timezone
handling the better - "sane" must include "user modifiable
rules" and "correct for all times, past and future, for
which the rules are known", which is a combination only the
ado implementation supports that I'm aware of.

    > However I am having some trouble reconciling the Rule
    > format with the format we use, which is also the POSIX standard
    > for timezone strings (as far as I can tell, looking at my
    > POSIX doc).  The problem is in the area of shifting to and from
    > Daylight Savings Time.  Our format is to use a Julian day,
    > a month/week/day, or a week/day format.

The format in the zone files is not the most crucial thing,
what's most important is the existance of the source file
that can be edited on site to allow for sudden and unexpected
changes in the rules, while retaining historical accuracy.

Remaining compatible with the current files has the advantage
that what's currently distributed will work on your systems
without change, but that's less important than having something

    > It's different enough from
    > your Rule format that timezones defined in your format (such as Sun >= 11)
    > do not work in our format for more than a few years at best (is
    > that the 2nd week of the month?  The 3rd week?  It shifts.)

The ado format is completely general and precise, it's sometimes
confusing till you get used to it though.   Its also concise.
Sun>=11 could be the 2nd or 3rd week, which might be what's
wanted (the legislators might actually say the first Sunday
on or after the eleventh - perhaps not in the US, but in Aust
they do things like that all the time).   More probably that
would be used to specify the 3rd last Sunday in a month with
30 days, which could be the 2nd or 3rd Sunday (month could have
4 or 5 Sundays in it) - that's the kind of rule we see all the
time.  To Specify the second Sunday one would use Sun>=8, and
for the third, Sun>=15 - for the last in a month of 31 days
Sun>=25, 2nd last Sun>=19, 3rd last Sun>=12 .. subtract one for
months with 30 days, subtract 3 for February in ordinary years,
fortunately, February isn't usually a month with DST shifts,
or "last Sunday" type rules would be very complicated by leap

    > Are there alternate ways of expressing timezones?

Without doubt.   Just make sure that rules like "last Sunday"
and "2nd last Sunday" are easy to say in a general way (which
"month/week/day" doesn't let you do, unless "week" can be
something like -1 or -2).   Also make sure can express obscure
rules like "the first Sunday on or after the 11th of the month".


More information about the tz mailing list