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.

The best way to do that would simply be to pick up Arthur's *code*, as well, and put it into SCO UNIX (SunOS 4.x, System V Release 4, and many other versions of UNIX have already done so); modulo bugs, it *fully* supports the POSIX standard for the TZ environment variable, as well as supporting the nicer "Olson" scheme (e.g., to get US Pacific time, set "TZ" to ":US/Pacific", rather than to whatever convoluted string is required for the POSIX scheme).

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

Unfortunately, as you note, the "Mm.n.d" scheme specified in POSIX does not appear to allow rules of the form "Sun>=11" to be expressed (sometimes it's the Sunday of the 3rd of the weeks in the month that have a Sunday, which would be "Mm.3.0", and sometimes it's the Sunday of the 2nd of the weeks in the month that have a Sunday, which would be "Mm.2.0" - the "n" im "Mm.n.d" doesn't mean "the nth week of the month", it means "the nth of the weeks in the month that actually have a day d", e.g. if d is 0, it's "the nth of the weeks in the month that have a Sunday"). The "Mm.n.d" scheme can, however, specify things such as "third Sunday in the month", which would be "Mm.3.0"; the Olson scheme can also specify that, as "Sun>=15". I believe the way to map from "Mm.n.d" to an Olson-style scheme is that Mm.n.d meaning "nth d-day of month m", maps to IN ON month_name(m) day_name(d)>=(1 + n*7) where "day_name(d)" is the name of day "d", e.g. "day_name(0)" is "Sun", "day_name(1)" is "Mon", etc.. If "1 + n*7" is greater than the number of days in the month, the "ON" field would be "last{day_name(d)}", e.g. Thus, for example: M1.1.0 maps to IN ON Jan Sun>=1 M1.2.0 maps to IN ON Jan Sun>=8 and so on, up to M1.5.0 which would map to IN ON Jan Sun>=36 except that no month has 36 days, so it'd map to IN ON Jan lastSun However, if the number after the ">=" isn't a multiple of 7 plus 1, I don't think there's a way to map that back into an "Mm.n.d" value. If there are any countries where the rules require an Olson-style specification other than "XXX>=(1 + n*7)", that's a strong argument in favor of just picking up the Olson code and using that (given that, as noted, it supports POSIX-style TZ settings, as well as settings that just cause a compiled file to be read in). If there *aren't* any such countries, the time zone files should be cleaned up.

> From: mommy <peggyd@sco.COM> > To: ado@elsie.nci.nih.gov > Date: Fri, 6 May 94 10:59:55 PDT > Message-Id: <9405061059.aa21366@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 useable. > 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 years! > 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". kre