Rajendra is not on the time zone mailing list; be sure to address replies appropriately. --ado -----Original Message----- From: Dodhiawala, Rajendra [SMTP:raj.dodhiawala@cacheflow.com] Sent: Tuesday, February 15, 2000 4:42 PM To: tz@elsie.nci.nih.gov Subject: Time Zone question I have looked at various resources for Time Zone data and found your tzcode, tzdata files to be most useful. Unfortunately, there is one piece of information I have not be able to locate on any of the TimeZone-related resources on the Internet: - What is a good way to display time such that TZ info is absolutely clear. ISO 8601 falls short of this. For example, YYYY-MM-DDTHH:mm:ss-08:00 is insufficient because -08:00 is -07:00 in the summer and thus indistinguishable from Arizona which also uses -07:00. Adding the timezone makes sense, as in YYYY-MM-DDTHH:mm:ss-07:00PST Is there any standard for this or precedence on how this is handled in current (popular?) operating systems. Any other pointers? Finally, is there any program/script (for Linux, for example) that will display all the abbreviations based on the rules in the zone.tab and continent files? Just the most recent abbreviation will do. Such a program would eliminate errors when manually extracting zone abbreviations. Appreciate your response, --Raj
From: Dodhiawala, Rajendra [SMTP:raj.dodhiawala@cacheflow.com] Sent: Tuesday, February 15, 2000 4:42 PM - What is a good way to display time such that TZ info is absolutely clear. I'd use the value of the TZ environment variable. It might be helpful to canonicalize it, e.g. replace 'US/Pacific' with 'America/Los_Angeles', and replace 'CET-1CEST-2,M3.5.0/02:00,M10.5.0/03:00' with 'CET-1CEST,M3.5.0,M10.5.0/3', but that would take some work. Is there any standard for this or precedence on how this is handled in current (popular?) operating systems. zdump -v outputs TZ's value.
From: Dodhiawala, Rajendra [SMTP:raj.dodhiawala@cacheflow.com] Sent: Tuesday, February 15, 2000 4:42 PM
- What is a good way to display time such that TZ info is absolutely clear.
I'd use the value of the TZ environment variable.
It might be helpful to canonicalize it, e.g. replace 'US/Pacific' with 'America/Los_Angeles', and replace 'CET-1CEST-2,M3.5.0/02:00,M10.5.0/03:00' with 'CET-1CEST,M3.5.0,M10.5.0/3', but that would take some work.
Is there any standard for this or precedence on how this is handled in current (popular?) operating systems.
zdump -v outputs TZ's value.
On some platforms. On others, not: tooting$ uname -sr SunOS 5.5.1 tooting$ zdump tooting$ zdump -v tooting$ and, perhaps more relevant to somebody at CacheFlow: ecco*> version NetApp Release 5.3.4R3: Thu Jan 27 12:08:07 PST 2000 ecco*> zdump zdump not found. Type '?' for a list of commands ecco*> zdump -v zdump not found. Type '?' for a list of commands ecco*> timezone Current time zone is US/Pacific (Yes, it could have been set to America/Los_Angeles; whoever configured that filer didn't do so, perhaps because they're still used to the old names - those being, as far as I can tell, the only ones Solaris supports, at least as of 2.6, that being the newest Solaris release we have here.) I.e., we're not running UNIX on our products, and they're not running it on their products either, as far as I know; if they're using the Olson time zone code on their Web-caching appliances, as we are on our file server and Web-caching appliances, there's probably some mechanism by which they can fetch the name of the current time zone, even if they, like we, have no notion of environment variables.
From: Guy Harris <guy@netapp.com> Date: Tue, 15 Feb 2000 14:46:02 -0800 (PST)
zdump -v outputs TZ's value.
On some platforms. On others, not: tooting$ uname -sr SunOS 5.5.1 tooting$ zdump tooting$ zdump -v Sorry, my comment was too terse. I should have written that `zdump -v ZONE' outputs ZONE, where ZONE is the value of the TZ environment variable. That is how the latest zdump internally implements the translation from the string 'ZONE' to a series of clock transitions. E.g.: 15-red.twinsun.com $ uname -sr SunOS 5.5.1 16-red.twinsun.com $ zdump -v US/Pacific US/Pacific Tue Feb 15 17:00:55 2000 PST US/Pacific Fri Dec 13 20:45:52 1901 GMT = Fri Dec 13 13:45:52 1901 isdst=0 ... SunOS 5.5.1 is running an old version of zdump. The latest tzcode zdump outputs something a bit different, but `zdump -v US/Pacific' still outputs `US/Pacific' on each line. ecco*> version NetApp Release 5.3.4R3: Thu Jan 27 12:08:07 PST 2000 ... ecco*> timezone Current time zone is US/Pacific Good point. In other words, even if your system has no notion of the "TZ environment variable", you print the value that you'd use for TZ if you were running tzcode.
participants (3)
-
Guy Harris -
Olson, Arthur David (NCI) -
Paul Eggert