jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (12/02/90)
In article <28082@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >Of course, now that Unix is being `internationalized', someone will >have to fix `cal'. Clearly the right answer is to adopt the System V >convention, and code the rules into an environment variable. :-) >(The above was intended as a sarcastic comment about SV `TZ' rules. >Why POSIX did not just adopt the Arthur Olson approach is beyond me.) OK...so what was the Arthur Olson approach? The TZ setup, at least in the System V release 2 systems I've used, seems like a very usable approach. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "...flames are a specific art form of Usenet..." -- Gregory C. Woodbury
gwyn@smoke.brl.mil (Doug Gwyn) (12/03/90)
In article <4393@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >OK...so what was the Arthur Olson approach? The TZ setup, at least in the >System V release 2 systems I've used, seems like a very usable approach. While there is nothing wrong with using an environment variable to name the desired time zone, there IS something wrong with trying to encode detailed time conversion rules within it.
guy@auspex.auspex.com (Guy Harris) (12/09/90)
>OK...so what was the Arthur Olson approach? Have the rules for changing between standard and summer time represented as a list of times/dates at which the offset from GMT changes, corresponding offsets, flags indicating whether this is standard or summer time, and abbreviations for the time zone. Have a compiler that turns various specifications for the rules into such a list, and store that list in a file. Have "tzset()" and company load up the table from those files; the setting of the TZ environment variable specifies the file to load. >The TZ setup, at least in the System V release 2 systems I've used, >seems like a very usable approach. It seems so only under some circumstances. Problems with it: 1) as it appears in AT&T releases prior to S5R3.1, *all* it can specify is the time zone abbreviation for standard time, the offset from GMT for standard time, and the optional time zone abbreviation for summer time if summer time is used. The actual rules for when the times change are *hardcoded* into a library routine. Needless to say, this sucks big time if you live in an area where the rules don't match those hardcoded into the library routine. Areas outside the US don't use the same rules as the US (even Canada skipped Tricky Dicky's modifications of the rules in the '70s, as far as I know); areas *inside* the US don't use the rules that were found in most if not all UNIX systems, because the rules changed in 1987 and UNIX systems made before then - and even lots made after then - had the old rules. (The rule change in question was what originally prompted Olson's work on this stuff.) It also didn't handle areas with time zones not offset from GMT by an even number of hours; yes, they exist. 2) as it appears in S5R3.1, you can specify the rules for the *current* year, specifying the date and time at which summer time starts and the date at which it ends. You can also specify the offset from GMT of summer time, if it doesn't happen to be one hour off from the offset of standard time (e.g., "double daylight savings time" with the clock shifting two hours). It handles areas with time zones not offset from GMT by an even number of hours. It also lets you specify not only the dates when the clock moves forward or back, but the *time of day* when it happens; yes, not everybody does it at 2AM local time. This does let you convert UNIX times to local time if the time is in the current year, and most times are probably in the current year most of the time; however, close only counts in horseshoes - not *all* times are in the current year, and if it's right after January 1, a fair number of e.g. times on files are not in the current year. What's more, it requires the system administrator to change the system time zone every year. The syntax is a bit sucky, in that the dates are specified as day numbers within the year; *I* sure don't think in those terms, and don't have any table to give me that information conveniently. Maybe AT&T gives out calendars like that, but I sure don't have one here.... 3) the POSIX scheme lets you specify certain kinds of repeating rules, e.g. "first Sunday in October", so that you don't have to change the time zone every year, can have some dates outside the current year converted correctly, and don't have to deal with day numbers relative to the beginning of the year. Unfortunately, this *still* doesn't handle rules that *aren't* repeating. The US rules generally repeat, but if you want to include pre-1987 and post-1987 times, they don't. Other countries change their rules fairly frequently, e.g. Australia (one of the other people who worked on the Olson time zone stuff was Robert Elz, an Australian; he had a very *definite* incentive for doing that). According to the person who contributed the most recent rules for Israel, prior to 1989, the rules changed every year, and from 1989 onwards summer time commences midnight of the first Saturday night following Passover, and standard time is reinstated "on the Saturday night whereupon Jews following the Ashkenazi (European) rite begin to recite the Selichot (forgiveness) prayers prior to the Jewish Lunar New Year). On top of that, if you want to find out what time it is now in some other country, you have to know what the right rules and GMT offset are, and set TZ based on that. 4) the Olson scheme deals with all the objections above: since the file contains a list of times at which the offset from GMT changes, it can represent any rules that fit within the file; they don't have to be described by some simple repeating rule. The files are generally limited to 370 transitions, which is enough to handle 138 years of the proposed US scheme wherein the transitions are different in Presidential election years - or a bit more than a year's worth of solar time (corrected daily to the nearest second), although that still has the "only within the current year" limitation and may now be obsolete if the Saudis no longer use solar time. The offsets are in seconds, and the transition times are UNIX times, so time zones not an integral number of hours from GMT can be handled, and the transition times aren't hard-coded. Except in areas using Solar time, they can convert dates in the past all the way to 1970, if the rules have been put into a file; they can attempt to convert dates in the future, under the assumption that the rules to be used are known at the time the rule file is made. The rule file syntax is fairly friendly; you don't have to know the day number within a year of a date. If you want to know what time it is in Japan, you can do TZ=Japan date in the Bourne/Korn/Bourne-again shells, or something slightly more annoying in the C shell (thanks to its lack of a convenient ability to override an environment variable setting for one command). You don't have to already know what the offset from GMT for Japan is. And the cost is small. The most recent set of files, as they appear in SunOS 4.1 (BTW, the rules files are in a machine-independent format; that was one of my contributions to this stuff), take up 238KB of disk space (8K/1K file system), and include a fair number of countries. The main memory overhead for the table is less than 1K; the code takes up about 8.8K on a SPARC (SunOS 4.1 version), and requires about 230 bytes of data+BSS. The time spent loading the table wasn't very large, either, when I tested it on various machines (diskless Sun-3/50, 3B2), and you only do it once, not once per date. BSD picked it up after 4.3BSD; SunOS picked it up in SunOS 4.0; various other vendors have picked it up - including AT&T in System V Release 4.