RE: Updated Australian time zone names/strings
At the end of this letter there's a blast from the past: results of a 1993 survey of time zone abbreviations. At least at that time, and at least in the scope of the survey, use of abbreviations such as "AEST" was very uncommon; this was (at least in part) what motivated the use of abbreviations such as "EST" for Australian time zones. Use of abbreviations such as "AEST" has seemingly become more common; see, for example, http://www.abc.net.au/ra. But as Paul Eggert's recent survey indicates, "EST" still seems to hold sway. I'd conclude that it's appropriate to leave zones such as "Australia/Brisbane" as is to avoid unnecessary change. A possibility would be to add lines such as Zone Australia/CST 9:30 Aus CST Zone Australia/ACST 9:30 Aus ACST Zone Australia/CXT 9:30 Aus CST/CDT Zone Australia/ACXT 9:30 Aus ACST/ACDT to the "australasia" file; this would let folks who wanted specific abbreviations to get them. --ado
From ado Thu Jun 10 20:28:51 1993 Return-Path: <ado> Received: by bossie.nci.nih.gov (4.1/SMI-4.1) id AA22772; Thu, 10 Jun 93 20:28:51 EDT Date: Thu, 10 Jun 93 20:28:51 EDT From: ado (Arthur David Olson) Message-Id: <9306110028.AA22772@bossie.nci.nih.gov> To: tz Subject: time zone survey Status: RO
Attached are results from a casual time zone survey. Last week I ran through the news articles on nih-csl.dcrt.nih.gov (the nntp newsfeed system for elsie.nci.nih.gov), getting the "Date: " and "Message-ID: " line from each article. Article file names were obtained from the news history file to ensure that any cross-posted articles would only be used once. I tossed out data with unzoned time stamps, data without a recognizable domained system name in the Message-ID, and data from ".com" sites. This left 17,912 date/name pairs. I massaged the data into the form... 05210205 (AEST) megalink.apana.org.au 05010053 +0000 compex.e-burg.su ...where the first field gives two digits each of month, day, hour, and minute from the Date, the second field gives the time zone that appeared in the Date, and the third field is the system name from the Message-ID. This data is available in the file ~ftp/pub/zonesurvey on elsie.nci.nih.gov (128.231.16.1). Eighty-nine different zones showed up (sorted alphabetically here): (AEST) +0000 +0001 +0100 +02 +0200 +0300 +0400 +0500 +0530 +0600 +0611 +0700 +0730 +0800 +0930 +1 +1000 +1100 +1200 +1300 +1700 -0000 -0100 -0300 -0400 -0500 -0520 -0600 -0700 -0800 -1 -1000 -1200 -600 ACST ADT AEST AET ARG AST BSC BST CDT CED CEST CET CST DST EDT EDZ EET EMT EST GMT GMT+01 GMT+0200 GMT+1 GMT+12 GMT+1200 GMT+2 IDT IST JST LCL MDT MED MES MEST MESZ MET MEWT MEZ MST NDT NZDT NZST PDT PST SGP TUR TZONE U UT WET WET+0100 WST XDT Y The number of times each zone showed up (sorted by number of times here): 3820 -0400 1925 EDT 1902 -0500 994 EST 919 -0700 913 CDT 748 +0000 690 +0200 664 CST 655 PDT 621 +0100 583 -0600 499 +1000 467 MDT 398 PST 275 +1200 211 BST 170 +0001 153 MET 138 -0800 135 MST 123 +0300 116 CET 98 +0800 97 -0300 53 +0400 51 +0930 45 -0100 36 +1300 35 WET 33 -0000 27 UT 23 ACST 22 MEZ 22 NZST 20 +1700 20 GMT+12 17 IDT 16 TUR 14 MESZ 9 +02 8 MEST 8 WET+0100 7 +0600 7 CED 7 CEST 7 LCL 6 AET 6 DST 6 EET 6 EMT 5 AST 5 GMT 5 GMT+01 5 GMT+0200 5 U 4 -1000 4 IST 3 +0700 3 +1100 3 -0520 3 -1200 3 -600 3 EDZ 3 TZONE 3 Y 2 ADT 2 ARG 2 BSC 2 GMT+1200 2 MED 2 MES 2 SGP 1 (AEST) 1 +0500 1 +0530 1 +0611 1 +0730 1 +1 1 -1 1 AEST 1 GMT+1 1 GMT+2 1 JST 1 MEWT 1 NDT 1 NZDT 1 WST 1 XDT Aside from the 51 "+0930" articles from Australia, only four "oddball" numeric time zones show up, and each of them only shows up from one system (the Date and system name from the original data are shown here): 3 -0520 Wed, 2 Jun 93 22:22:00 -0520 freddy.ampr.ab.ca Thu, 3 Jun 93 20:08:00 -0520 freddy.ampr.ab.ca Sat, 5 Jun 93 16:05:00 -0520 freddy.ampr.ab.ca 1 +0530 1 Jun 93 15:30:55 +0530 imtech.ernet.in 1 +0611 Wed, 02 Jun 93 16:08:33 +0611 trashcan.hacktic.nl 1 +0730 6 Jun 1993 08:25:56 +0730 news.Colorado.EDU Time zone abbrevations that show up in tzdata93c.tar.Z files: ADT Atlantic Daylight Time AST Atlantic Standard Time BST British Standard Time CDT Central Daylight Time CET Central European Time CST Central Standard Time EDT Eastern Daylight Time EET Eastern European Time EST Eastern Standard Time IDT Israeli Daylight Time IST Israeli Standard Time JST Japanese Standard Time MDT Mountain Daylight Time MET Middle European Time MST Mountain Standard Time NZDT New Zealand Daylight Time NZST New Zealand Standard Time PDT Pacific Daylight Time PST Pacific Standard Time WET Western European Time WST Western Standard Time Time zone abbreviations that are fairly clear are: (AEST) Australian Eastern Standard Time (used only by one system) Fri, 21 May 93 02:05:36 (AEST) megalink.apana.org.au ACST Australian Central Standard Time 21 May 93 13:18:16 ACST state.systems.sa.gov.au Tue, 25 May 93 13:27:42 ACST cola.pax.tpa.com.au ... 4 Jun 93 00:47:42 ACST state.systems.sa.gov.au Sun, 06 Jun 93 19:13:17 ACST cola.pax.tpa.com.au AEST Australian Eastern Standard Time Fri, 04 Jun 93 21:47:10 AEST ese.escape.brisnet.org.au AET Australian Eastern Time (used only by one system) 10 May 93 08:50:04 AET licre.ludwig.edu.au 27 May 93 19:00:11 AET licre.ludwig.edu.au 28 May 93 12:46:13 AET licre.ludwig.edu.au 1 Jun 93 08:46:51 AET licre.ludwig.edu.au 1 Jun 93 09:02:16 AET licre.ludwig.edu.au 7 Jun 93 14:52:39 AET licre.ludwig.edu.au CED Central European Daylight 28 Apr 93 21:00:06 CED alphanet.alphanet.ch 27 May 93 22:53:59 CED sourcery.han.de 28 May 93 18:36:06 CED sourcery.han.de 1 Jun 93 22:16:54 CED sourcery.han.de 1 Jun 93 22:22:52 CED sourcery.han.de 1 Jun 93 22:45:24 CED sourcery.han.de 2 Jun 93 21:05:10 CED sourcery.han.de CEST Central European Standard Time Tue, 25 May 93 07:26:34 CEST obula.nbg.sub.org Tue, 25 May 93 15:58:02 CEST obula.nbg.sub.org Wed, 26 May 93 12:46:27 CEST obula.nbg.sub.org Tue, 01 Jun 93 11:18:35 CEST obula.nbg.sub.org Wed, 02 Jun 93 08:42:25 CEST obula.nbg.sub.org Fri, 04 Jun 1993 17:45:26 CEST oktagon.rd.sub.org Sun, 06 Jun 93 20:44:27 CEST scrum.greenie.muc.de MED Middle European Daylight (used only by one system) 3 Jun 93 00:17:24 MED lifestyle.rhein-main.de 6 Jun 93 12:27:48 MED lifestyle.rhein-main.de MES Middle European Standard (used only by one system) Sat, 22 May 93 12:46:44 MES wolferts.ka.sub.org Sun, 06 Jun 93 15:05:50 MES wolferts.ka.sub.org MESZ Middle European Standard Zone Tue, 25 May 1993 17:49:06 MESZ email.tuwien.ac.at Wed, 26 May 1993 12:12:26 MESZ gwdu14.gwdg.de Wed, 26 May 93 14:03:58 MESZ lbl.gov Fri, 28 May 1993 00:02:42 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:03:34 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:04:26 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:12:50 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:13:56 MESZ nasim.sta.sub.org Fri, 28 May 1993 00:15:10 MESZ nasim.sta.sub.org Sat, 29 May 1993 01:30:40 MESZ nasim.sta.sub.org Tue, 01 Jun 1993 00:46:06 MESZ nasim.sta.sub.org Thu, 03 Jun 93 10:48:04 MESZ aie.wu-wien.ac.at Fri, 4 Jun 93 10:56:33 MESZ exaib.wu-wien.ac.at Fri, 4 Jun 93 11:06:41 MESZ exaib.wu-wien.ac.at MEST Middle European Standard Time Tue, 25 May 93 12:45:47 MEST xivic.bo.open.de Tue, 25 May 93 14:20:53 MEST xivic.bo.open.de Tue, 25 May 93 14:48:22 MEST xivic.bo.open.de Wed, 26 May 93 23:22:22 MEST joker.wes.open.de Sat, 29 May 1993 18:22:55 MEST netmbx.netmbx.de Sat, 29 May 1993 18:21:07 MEST netmbx.netmbx.de Sun, 30 May 1993 12:57:21 MEST netmbx.netmbx.de Tue, 1 Jun 1993 21:51:09 MEST netmbx.netmbx.de MEZ Middle European Zone (used primarily in Germany) Mon, 10 May 93 20:47:50 MEZ rhrz.uni-bonn.de Wed, 26 May 93 12:59:57 MEZ vm.univie.ac.at ... Sun, 06 Jun 1993 14:32:28 MEZ sartar.toppoint.de Sun, 06 Jun 1993 18:37:50 MEZ sartar.toppoint.de UT Universal Time (used only by one system) 29 May 1993 21:14 UT kelvin.jpl.nasa.gov 31 May 1993 15:40 UT kelvin.jpl.nasa.gov ... 3 Jun 1993 21:36 UT kelvin.jpl.nasa.gov 4 Jun 1993 00:20 UT kelvin.jpl.nasa.gov WET+0100 Western European Time+0100 8 Apr 93 15:00:02 WET+0100 ittpub.nl 1 Jun 93 19:26:08 WET+0100 ittpub.nl 2 Jun 93 16:17:13 WET+0100 ittpub.nl 2 Jun 93 20:24:36 WET+0100 ittpub.nl 4 Jun 93 13:32:33 WET+0100 ittpub.nl 4 Jun 93 13:39:50 WET+0100 ittpub.nl 4 Jun 93 13:47:53 WET+0100 ittpub.nl 4 Jun 93 14:08:22 WET+0100 ittpub.nl Time zone abbreviations that are guesswork are: ARG Argentina? Tue, 25 May 93 12:46:21 ARG satlink.net Thu, 27 May 93 07:36:01 ARG satlink.net BSC ? Tue, 25 May 1993 10:51:05 BSC FINHUTC.HUT.FI Tue, 1 Jun 1993 11:57:00 BSC brfapesp.bitnet DST Daylight Saving Time? Thu, 27 May 93 11:00:24 DST cmrra.ca Thu, 27 May 93 23:31:02 DST cmrra.ca Fri, 28 May 93 17:26:14 DST cmrra.ca Sat, 29 May 93 16:48:42 DST cmrra.ca Sat, 29 May 93 16:54:30 DST cmrra.ca Sun, 30 May 93 14:38:30 DST cmrra.ca EDZ ? Mon, 31 May 93 18:14:42 EDZ wship.nullnet.fi Fri, 04 Jun 93 20:41:41 EDZ swob.nullnet.fi Fri, 04 Jun 93 20:53:45 EDZ swob.nullnet.fi EMT ? 28 Apr 1993 12:08:23 EMT alf.uib.no 29 Apr 1993 11:15:44 EMT alf.uib.no 29 Apr 1993 11:17:15 EMT alf.uib.no 28 May 1993 17:56:54 EMT alf.uib.no 1 Jun 1993 19:43:42 EMT alf.uib.no 3 Jun 1993 18:09:42 EMT alf.uib.no MEWT ? 12 May 93 07:41:03 MEWT mble.philips.be LCL LoCaL time? Tue, 1 Jun 1993 09:18:43 LCL kona.cc.mcgill.ca Wed, 2 Jun 1993 07:48:00 LCL mp.cs.niu.edu Wed, 2 Jun 1993 13:44:00 LCL mp.cs.niu.edu Thu, 3 Jun 1993 09:33:00 LCL oas2-tic.safb.af.mil Thu, 3 Jun 1993 08:25:39 LCL grouse.umesve.maine.edu Fri, 4 Jun 1993 20:09:05 LCL CUVMB.COLUMBIA.EDU Fri, 4 Jun 1993 20:19:59 LCL CUVMB.COLUMBIA.EDU NDT ? Tue, 25 May 1993 15:39:29 NDT UBVM.CC.BUFFALO.EDU SGP ? Mon, 31 May 93 15:43:36 SGP uwm.edu Fri, 4 Jun 93 10:20:26 SGP uwm.edu TUR Turkey? Wednesday, 5 May 1993 23:23:11 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:03:58 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:05:39 TUR TRMETU.BITNET Wednesday, 26 May 1993 09:06:26 TUR TRMETU.BITNET Wednesday, 26 May 1993 20:47:38 TUR TRMETU.BITNET Thursday, 27 May 1993 10:15:14 TUR TRMETU.BITNET Thursday, 27 May 1993 12:28:59 TUR TREARN.BITNET Thursday, 27 May 1993 13:20:19 TUR TRMETU.BITNET Thursday, 27 May 1993 15:20:12 TUR TRMETU.BITNET Friday, 28 May 1993 11:01:42 TUR TREARN.BITNET Friday, 28 May 1993 12:53:52 TUR TRMETU.BITNET Sunday, 30 May 1993 12:15:24 TUR TREARN.BITNET Saturday, 29 May 1993 12:46:01 TUR TRMETU.BITNET Monday, 31 May 1993 21:44:49 TUR TRMETU.BITNET Saturday, 5 Jun 1993 18:30:45 TUR TREARN.BITNET Sunday, 6 Jun 1993 13:14:56 TUR TREARN.BITNET TZONE ? Mon, 31 May 1993 05:01:19 TZONE VAXF.COLORADO.EDU Wed, 2 Jun 1993 19:59:49 TZONE carson.u.washington.edu Fri, 4 Jun 1993 09:21:33 TZONE sunburn.uwaterloo.ca XDT ? Tue, 25 May 1993 10:20:55 XDT sfanet.nrl.navy.mil The results make me think there's little prospect of discovering useful time zone information (in particular, time transitions that don't already show up in tzdata93c.tar.Z) from running through news articles; someone with an account on a site that does extensive archiving of news might prove me wrong. --ado
"Olson, Arthur David (NCI)" wrote: | At the end of this letter there's a blast from the past: results of a 1993 | survey of time zone abbreviations. At least at that time, and at least in | the scope of the survey, use of abbreviations such as "AEST" was very | uncommon; this was (at least in part) what motivated the use of | abbreviations such as "EST" for Australian time zones. This is a kind of chicken/egg problem: because the tzdata files don't offer AEST and friends, people have to jump through hoops to use them; most don't bother. | I'd conclude that it's appropriate to leave zones such as | "Australia/Brisbane" as is to avoid unnecessary change. Just for the record, I'm still against this. | A possibility would be to add lines such as | Zone Australia/CST 9:30 Aus CST | Zone Australia/ACST 9:30 Aus ACST | Zone Australia/CXT 9:30 Aus CST/CDT | Zone Australia/ACXT 9:30 Aus ACST/ACDT | to the "australasia" file; this would let folks who wanted specific | abbreviations to get them. Certainly, if I could have one of these to use as an alternative to "Australia/Brisbane", that would be an acceptable compromise.
Date: Tue, 17 Apr 2001 10:52:24 +1000 From: Greg Black <gjb@gbch.net> Message-ID: <nospam-987468745.32363@maxim.gbch.net> | This is a kind of chicken/egg problem: because the tzdata files | don't offer AEST and friends, people have to jump through hoops | to use them; most don't bother. Back in 1993 there was almost no use of the tz database, that was still comparatively early in its development (the 93b set of data is the oldest one I have managed to save). Before then, people set the timezone name in all kinds of weird and wonderful ways. | Certainly, if I could have one of these to use as an alternative | to "Australia/Brisbane", that would be an acceptable compromise. When I saw ado's message, before seeing your reply, I was going to reply and say that I didn't think that would work for you at all - that is, your primary aim seemed to be to be able to sort incoming mail where the timezone string was "EST" and you knew it was from somewhere in Eastern Aust, rather than eastern north America. To achieve that you need to somehow get other people to use a tz abbreviation that you like, creating tz db entries with exotic names and different abbreviations is unlikely to achieve that, people in Sydney are still going to pick Australia/Sydney 99 times out of a hundred. For your own use there has never been a problem, you have always been able to alter the TZ abbreviations that you use to anything that you would like them to be. Personally, I don't care if a few extra zones are created with wacky abbreviations - I don't think they'll change anything, except make the tz database that little bit bigger (and that's not a real problem). kre
Robert Elz wrote: | | This is a kind of chicken/egg problem: because the tzdata files | | don't offer AEST and friends, people have to jump through hoops | | to use them; most don't bother. | | Back in 1993 there was almost no use of the tz database, that was still | comparatively early in its development (the 93b set of data is the oldest | one I have managed to save). Before then, people set the timezone name | in all kinds of weird and wonderful ways. I seem to have been using it forever, but I expect you're right. | | Certainly, if I could have one of these to use as an alternative | | to "Australia/Brisbane", that would be an acceptable compromise. | | When I saw ado's message, before seeing your reply, I was going to reply | and say that I didn't think that would work for you at all - that is, your | primary aim seemed to be to be able to sort incoming mail where the timezone | string was "EST" and you knew it was from somewhere in Eastern Aust, rather | than eastern north America. To achieve that you need to somehow get other | people to use a tz abbreviation that you like, You're quite right -- it doesn't get me what I really want, but I've largely given up on that now as I can see that it's not at all likely to fly any time soon (if ever). | creating tz db entries with | exotic names and different abbreviations is unlikely to achieve that, | people in Sydney are still going to pick Australia/Sydney 99 times out of | a hundred. True -- but if there's an alternative in the tz database that's "better" than "Australia/Sydney", I'd be able to point to it and suggest that people either use the alternative or, preferably, stop using the abbreviations altogether and just use the +1000 or +1100 that we can all understand. | For your own use there has never been a problem, you have always been able | to alter the TZ abbreviations that you use to anything that you would like | them to be. I knew that. I used to use "AEST/AEDT" on my own email, but dropped the abbreviations a few years ago in favour of unadorned numeric zones. And it's not my email that's causing me grief :-)
I'm building the timezone files on a Tru64 machine and I receive from zic the error as bellow: zic -l CETCEST africa antarctica asia australasia backward etcetera europe factory northamerica pacificnew southamerica systemv solar87 solar88 solar89 "solar87", line 385: too many local time types (rule from "solar87", line 33) My Machine is OSF1 atopo01.opteway.com V5.0 1094 alpha and I got the latest olson tzdata tzdata2001a: africa backward iso3166.tab solar87 systemv zone.tab antarctica etcetera leapseconds solar88 yearistype.sh asia europe northamerica solar89 australasia factory pacificnew southamerica Please , have you an idea of this problem which prevents me from building the complete suite of timezone data files. The list of compiled timezone files is uncomplete as yoy can see bellow: bash-2.04$ cd /etc/zoneinfo bash-2.04$ ls Africa Asia CET Europe MET America Atlantic EET Factory Pacific Antarctica Australia Etc Indian WET The files bellow are not produced by the interrupted zic command Arctic Brazil Canada Chile CST6CDT Cuba Egypt Eire EST EST5EDT GB GB-Eire GMT GMT+0 GMT-0 GMT0 Greenwich Hongkong HST Iceland Iran Israel Jamaica Japan Kwajalein Libya ..... Thanks for your help. François REYGAGNE. Software Architect. opt[e]way S.A., 2881 route des Crêtes, BP308 06906 Sophia Antipolis Cedex, FRANCE tél: +33 (0)4 92 95 27 01 http://www.opteway.com
On Linux RedHat 6.2, kernel 2.4 I compile tzdata using zic. Everything is OK, the compiled data files are produced into /usr/local/etc/zoneinfo and when I compare to the current tzdata files /usr/share/zoneinfo I realized that the files bellow are missing in my new compiled directory iso31166.tab posix posixrules right zone.tab [root@freygagne tzdata2001a]# ../tzcode2001a/zic africa antarctica asia australasia backwar d etcetera europe factory northamerica pacificnew solar87 solar88 solar89 southamerica syst emv "backward", line 49: warning: hard link failed, symbolic link used "backward", line 50: warning: hard link failed, symbolic link used "backward", line 51: warning: hard link failed, symbolic link used "backward", line 52: warning: hard link failed, symbolic link used the symbolic links are GMT+0 GMT-0 GMT0 Greenwich Universal and Zulu Is it normal ? François REYGAGNE. Software Architect. opt[e]way S.A., 2881 route des Crêtes, BP308 06906 Sophia Antipolis Cedex, FRANCE tél: +33 (0)4 92 95 27 01 http://www.opteway.com
OSF1 adev01.opteway.com V5.0 1094 alpha make zic cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -DNOSOLAR -DHAVE_LONG_DOUBLE=1 -c -o zic.o zic.c cc: Error: zic.c, line 415: In the definition of the function "error", the promoted type of string is incompatible with the type of the corresponding parameter in a prior declaration. (promotmatch) To remove this compilation error I replace these 3 lines static void error P((const char * message)); BY static void error P((const char* const string)); and static void error(string) const char* const string; BY static void error(const char* const string); Is there a compiler option to disable the prototype checking. Upgrade the zic.c source code file by replacing the prototypes a la Ansi-C is a nightmare, very long... Is there a compiler option to disable the compiler error to prevent me from updating the C source files until no compilation error appears. François REYGAGNE. Software Architect. opt[e]way S.A., 2881 route des Crêtes, BP308 06906 Sophia Antipolis Cedex, FRANCE tél: +33 (0)4 92 95 27 01 http://www.opteway.com
/home/geneve/freygagne/OLSON/tzcode2001a> make all gcc -DTZDIR=\"/usr/local/etc/zoneinfo\" -c -o zic.o zic.c as0: No such file or directory make: *** [zic.o] Error 1 do you know the nature of this trouble ? By advance thanks.
From: "Olson, Arthur David (NCI)" <olsona@dc37a.nci.nih.gov> Date: Mon, 16 Apr 2001 18:27:19 -0400
A possibility would be to add lines such as Zone Australia/CST 9:30 Aus CST Zone Australia/ACST 9:30 Aus ACST Zone Australia/CXT 9:30 Aus CST/CDT Zone Australia/ACXT 9:30 Aus ACST/ACDT to the "australasia" file; this would let folks who wanted specific abbreviations to get them.
I can see two arguments against this approach: * It won't work in general, as you'll need separate Zones for each Australian state, even states that all use "CST", as the states often have differing rules for the DST transitions. * It opens the floodgates to everyone else who wants alternative abbreviations for a region (e.g. the French Canadians). Here's another possibility: add a TZ extension that would let users substitute their own abbreviations. E.g. one might write something like TZ='Australia/Sydney:AEST/AEDT' if one prefers AEST/AEDT. This would also support non-English locales (e.g. the French Canadians). There is the problem of specifying abbreviations for offsets other than latest standard- and daylight-saving-time, but I suppose we could specify a more-general syntax that would attack that problem too.
Date: Tue, 17 Apr 2001 01:58:35 -0700 (PDT) From: Paul Eggert <eggert@twinsun.com> Message-ID: <200104170858.BAA08429@green-office.twinsun.com> | I can see two arguments against this approach: Yes, both of those apply. | Here's another possibility: add a TZ extension that would let users | substitute their own abbreviations. We already have that. That is, we have TZ=/whatever/file/you/like and that file can contain whatever is appropriate (according to whoever set the TZ variable) already. Further it will support all of the historic abbreviations. Further, admins, if they desire can alter the system wide (no TZ setting) values trivially easily. The only question in all of this is what ought to be being distributed by you and ado (and to a lesser extent by the rest of this list) as being the "standard" (or at least, commonly accepted) abbreviations to use. Other than simply changing what is there, or creating a whole bunch of alternatives and then make it up to the local installer to pick, about the only thing I can see worth doing to the code/data might be to provide an option (set via an env var, or some other way - perhaps even something as crude as the perms on the tzdata file being used) which would cause the tz abbreviations to be always returned as a string like "+1000" (ie: the code does an sprintf of the offset, and that is what is returned as the abbreviation, rather than the EST thing). kre
From: Robert Elz <kre@munnari.OZ.AU> Date: Tue, 17 Apr 2001 17:36:47 +0700
about the only thing I can see worth doing to the code/data might be to provide an option (set via an env var, or some other way - perhaps even something as crude as the perms on the tzdata file being used) which would cause the tz abbreviations to be always returned as a string like "+1000" (ie: the code does an sprintf of the offset, and that is what is returned as the abbreviation, rather than the EST thing).
OK, how about this idea? If TZ='Australia/Sydney:' then use numeric abbreviations. The basic idea is to append a suffix that cannot possibly be part of a portable POSIX file name. Later on we could add other suffixes (perhaps after the ':') for other extensions. The latest POSIX draft adds support for numeric abbreviations. For example, TZ='<+1000>-10<+1100>,M10.5.0,M3.5.0/3' would be appropriate for those in Sydney who want to use next-generation POSIX-style TZ strings that generate "+1000" instead of "EST". Since POSIX is adding support for "+1000", it might be nice if the Olson extension added similar support.
Date: Fri, 20 Apr 2001 17:42:08 -0700 (PDT) From: Paul Eggert <eggert@twinsun.com> Message-ID: <200104210042.RAA08396@shade.twinsun.com> | OK, how about this idea? If TZ='Australia/Sydney:' then use numeric | abbreviations. The basic idea is to append a suffix that cannot | possibly be part of a portable POSIX file name. I guess we could, though I'm not overly enamoured with the "cannot possibly be part of a portable POSIX file name" part. We should certainly not be presuming that any such names can be used, and should not be naming zones in non-portable ways, but if someone decides to name a timezone file /path/to/EST:EDT (and it happens to work on his system) I'd prefer not to break things. Of course, it can be documented that ':' is magic in TZ file names (or what would otherwise be a TZ file name) but it does seem a bit ugly. The "alternative" form of TZ setting has more flexibility here, as they're defining a syntax for the value of the TZ variable which is not just "any local path name", and hence can shoe horn in almost anything they want. | Since POSIX is adding | support for "+1000", it might be nice if the Olson extension added | similar support. Yes, the only issue is just how that is made to happen. kre
participants (5)
-
francois reygagne -
Greg Black -
Olson, Arthur David (NCI) -
Paul Eggert -
Robert Elz