From: "Holger Kruse" Date: Fri, 07 Nov 1997 14:35:15 -0400 type "setenv TZ timestring" then "copy env:TZ envarc:". "timestring" depends on the season and on where you live. The format is - outside of daylight savings time (i.e. during winter): EST5 where EST is the name of your time zone, and 5 is the *negative* time difference to UTC (i.e. if you are 2 hours east of UTC then the value has to be -2, not 2). In Europe, Asia and Australia that number is usually 0 or negative, in America it is positive. See below for examples. - during daylight savings time (i.e. during summer): EST4EDT EST, 4: meaning the same as above. EDT is the name of your time zone during daylight savings time. Also make sure that you adjust the number (4 in the example) by one hour as required by your local daylight savings time conventions. Yes, I realize this is complicated, but I did not invent this scheme. It is used by the SAS/C time functions (which are used by Miami in several places), and was derived from older versions of Unix (before the I18N effort, when automatic time zone configuration/ adjustment was introduced). In newer versions of Miami the string is not only used by the SAS/C time functions, but also parsed directly by Miami, because the SAS/C time functions are insufficient for some purposes. I decided to use the same environment variable for this, instead of requiring the user to configure two separate time settings in the same way. AFAIK the name of the time zone does not really matter in either case. It is important that the number is right, though, and that the number starts *exactly* at the fourth character position. It is NOT correct to put some RFC-compliant time string into ENV:TZ, i.e. something like "EST", "EST (-0500)" or "-0500" will NOT work. Programs that require RFC-compliant time strings (e.g. email programs) needs to create them by themselves, either from Locale prefs, or by converting ENV:TZ, or by some other means or prior configuration. Some examples: winter summer US west coast PST8 PST7PDT US east coast EST5 EST4EDT Britain WET0 WET-1WEDT most of western Europe MET-1 MET-2MEDT The names for the European strings are often localized, and might not even be correct as specified above. That should not matter though. Just make sure that the first name (the one that precedes the number) has *exactly* three characters, and that the number is correct (*negative* time difference to UTC). -- Holger Kruse kruse@nordicglobal.com http://www.nordicglobal.com NO COMMERCIAL SOLICITATION ! ---------------------------------------------------------------------- From: Steve Bowman The first attachment is a post made by Fred Wright on 16-oct-97, which explains TZ somewhat, while the second attachment is a post I made 25-Sep-97 regarding my personal experiences with rc5 and TZ, which as we all know by now is not the correct TZ implementation. -- Steve Bowman - Melbourne, Australia [Attachment 1] - written by Fred Wright Some computers don't even know about timezones. Some do but not about automatic "daylight time" switching. Some do it right. Unix systems have always been timezone-aware, and used GMT (excuse me, UTC) internally, with the environment variable TZ specifying the timezone. This could be formatted as (e.g. PST8PDT for Pacific time). Daylight time changeover was automatic, but the rules for when to switch were built into the code, based on US rules. Newer Unix systems have zoneinfo files, which give a complete description of what the offsets are, what they are called, and when they change, including different rules for different years (remember the functions don't merely provide the current time, they need to be able to convert any arbitrary date/time for the proper timezone). The TZ variable is now treated as a filename of a zoneinfo file. The Amiga began as dumb as possible, with no knowledge of timezones and all timestamps being local-time based. Timezone awareness began in some third-party programs, making it somewhat disorganized. The SAS/C library attempts to handle TZ (if it exists) as in old Unix, but doesn't do it correctly because it doesn't understand automatic daylight time switching. E.g. you can use PST8PDT if you want, but it will be treated as an 8-hour offset year-round, and hence might as well be PST8. To get the proper offset in the summer time, it should be specified as PDT7. The Prefs/Locale in more recent versions of the OS has a similar problem, where there is no understanding of daylight time, and in the summer you need to click on the wrong part of the map to get the correct GMT offset. Ixemul implements the full-blown modern Unix zoneinfo mechanism, with the contents of TZ being treated as a filename in Etc:zoneinfo/. A separate variable IXGMTOFFSET keeps track of the offset from local time to GMT independently from TZ. The ixtimezone utility manipulates this, and even has a feature to switch your clock automatically on/off daylight time, but I don't recommend putting it in your startup as they suggest, since writing harddisk files (e.g. ENVARC:xxx) during a LoadWb often triggers disk validation and occasionally causes crashes. Also, when it does switch, it updates ENVARC:IXGMTOFFSET without changing the battery clock, so the next boot will be wrong unless you do your own SetClock save. There's some other package (ClockDaemon, I think) with a *yet different* and incompatible interpretation of the TZ variable. This is trying to encode the DST-switching rules directly into the string. If you use both ixemul-based programs and SAS/C-based programs, then TZ has to be set time-of-year dependently to make SAS/C happy, and whatever you use for TZ should exist as a file in Etc:zoneinfo, probably by copying from the file with the correct name. At each DST change, the system time, the battery clock, IXGMTOFFSET, TZ, and Prefs/Locale all need to be changed. The first three can be taken care of by doing: ixtimezone check_dst SetClock save Then TZ and Locale/Prefs need to be adjusted manually. Fred Wright ---------------------------------------------------------------------- [Attachment 2] - by Steve Bowman Regarding ENV:TZ, here are my experiences. In Melbourne, we are not in standard (not summer) time at the moment, which is GMT +10 Hrs. Setting TZ to "EST-10" did the trick, so rc5 displays correct GMT. In fact, the "EST" letters don't seem too important - XXX, ABC, JOE seem to work also. No letters ie. "-10" gives me local time: "-10": GMT +10 Hrs is displayed "X-10": GMT +10 Hrs " " " "XX-10": GMT +20 Hrs " " " (??) "XXX-10": GMT is correctly displayed "XXXX-10": GMT +11 Hrs is displayed "XXXXX-10": GMT +11 Hrs " " " "XXXXXX-10": GMT +11 Hrs " " " So, it seems only the 3 letter combination is correct. What about when we go into summertime? Well, I reset the system clock to one hour ahead, and tried the following, à la "MET-02MET" someone posted: "XXX-10X" : GMT +2 Hrs is displayed "XXX-10XX" : GMT +2 Hrs " " " "XXX-10XXX" : GMT +2 Hrs " " " "XXX-10XXXX": GMT +2 Hrs " " " No matter if the system clock is set to December or July, the same results. I did read that the SAS implementation is broken... So, for winter, I use "EST-10", and Summer "EDT-11". Maybe the letters are important for certain applications. Does anyone know? Regards, -- Steve Bowman - Melbourne, Australia