> 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