Here are changes (relative to what's currently available via ftp) to deal with time zone abbreviation issues. 1. The use of "??" as an abbreviation in the solar* files is eliminated. 2. The zic command warns about non-POSIX abbreviations. 3. The zdump command warns about non-POSIX abbreviations if its "-v" flag is used. 4. localtime.c is changed to restrict characters in abbreviations to [a-zA-Z0-9 :+-] (replacing other characters with 'X'), and to restrict abbreviation lengths to 16 (truncating longer abbreviations). Both zic.c and localtime.c have the long Factory "abbreviation" grandparented in. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Apr 4 11:24:31 2005 --- new/Makefile Thu May 26 12:42:13 2005 *************** *** 1,4 **** ! # @(#)Makefile 7.108 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.109 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 111,117 **** # -DNO_RUN_TIME_WARNINGS_ABOUT_YEAR_2000_PROBLEMS_THANK_YOU=1 # if you do not want run time warnings about formats that may cause # year 2000 grief ! # GCC_DEBUG_FLAGS = -Dlint -g -O -fno-common \ -Wall -Wcast-qual -Wconversion -Wmissing-prototypes \ -Wnested-externs -Wpointer-arith -Wshadow \ --- 111,119 ---- # -DNO_RUN_TIME_WARNINGS_ABOUT_YEAR_2000_PROBLEMS_THANK_YOU=1 # if you do not want run time warnings about formats that may cause # year 2000 grief ! # -DZIC_MAX_ABBR_LEN_WO_WARN=3 ! # (or some other number) to set the maximum time zone abbreviation length ! # that zic will accept without a warning (the default is 6) GCC_DEBUG_FLAGS = -Dlint -g -O -fno-common \ -Wall -Wcast-qual -Wconversion -Wmissing-prototypes \ -Wnested-externs -Wpointer-arith -Wshadow \ diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Apr 4 11:24:32 2005 --- new/localtime.c Thu May 26 15:02:36 2005 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.91"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.93"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 22,27 **** --- 22,40 ---- #include "fcntl.h" #include "float.h" /* for FLT_MAX and DBL_MAX */ + #ifndef TZ_ABBR_MAX_LEN + #define TZ_ABBR_MAX_LEN 16 + #endif /* !defined TZ_ABBR_MAX_LEN */ + + #ifndef TZ_ABBR_CHAR_SET + #define TZ_ABBR_CHAR_SET \ + "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 :+-" + #endif /* !defined TZ_ABBR_CHAR_SET */ + + #ifndef TZ_ABBR_ERR_CHAR + #define TZ_ABBR_ERR_CHAR 'X' + #endif /* !defined TZ_ABBR_ERR_CHAR */ + /* ** SunOS 4.1.1 headers lack O_BINARY. */ *************** *** 124,129 **** --- 137,143 ---- static long detzcode P((const char * codep)); static const char * getzname P((const char * strp)); + static const char * getqzname P((const char * strp, const char delim)); static const char * getnum P((const char * strp, int * nump, int min, int max)); static const char * getsecs P((const char * strp, long * secsp)); *************** *** 269,274 **** --- 283,306 ---- tzname[ttisp->tt_isdst] = &sp->chars[ttisp->tt_abbrind]; } + /* + ** Finally, scrub the abbreviations. + ** First, replace bogus characters. + */ + for (i = 0; i < sp->charcnt; ++i) + if (strchr(TZ_ABBR_CHAR_SET, sp->chars[i]) == NULL) + sp->chars[i] = TZ_ABBR_ERR_CHAR; + /* + ** Second, truncate long abbreviations. + */ + for (i = 0; i < sp->typecnt; ++i) { + register const struct ttinfo * const ttisp = &sp->ttis[i]; + register char * cp = &sp->chars[ttisp->tt_abbrind]; + + if (strlen(cp) > TZ_ABBR_MAX_LEN && + strcmp(cp, GRANDPARENTED) != 0) + *(cp + TZ_ABBR_MAX_LEN) = '\0'; + } } static int *************** *** 470,475 **** --- 502,528 ---- } /* + ** Given a pointer into an extended time zone string, scan until the ending + ** delimiter of the zone name is located. Return a pointer to the delimiter. + ** + ** As with getzname above, the legal character set is actually quite + ** restricted, with other characters producing undefined results. + ** We choose not to care - allowing almost anything to be in the zone abbrev. + */ + + static const char * + getqzname(strp, delim) + register const char * strp; + const char delim; + { + register char c; + + while ((c = *strp) != '\0' && c != delim) + ++strp; + return strp; + } + + /* ** Given a pointer into a time zone string, extract a number from that string. ** Check that the number is within a specified range; if it is not, return ** NULL. *************** *** 753,760 **** stdlen = (sizeof sp->chars) - 1; stdoffset = 0; } else { ! name = getzname(name); ! stdlen = name - stdname; if (stdlen < 3) return -1; if (*name == '\0') --- 806,823 ---- stdlen = (sizeof sp->chars) - 1; stdoffset = 0; } else { ! if (*name == '<') { ! name++; ! stdname = name; ! name = getqzname(name, '>'); ! if (*name != '>') ! return (-1); ! stdlen = name - stdname; ! name++; ! } else { ! name = getzname(name); ! stdlen = name - stdname; ! } if (stdlen < 3) return -1; if (*name == '\0') *************** *** 767,775 **** if (load_result != 0) sp->leapcnt = 0; /* so, we're off a little */ if (*name != '\0') { ! dstname = name; ! name = getzname(name); ! dstlen = name - dstname; /* length of DST zone name */ if (dstlen < 3) return -1; if (*name != '\0' && *name != ',' && *name != ';') { --- 830,847 ---- if (load_result != 0) sp->leapcnt = 0; /* so, we're off a little */ if (*name != '\0') { ! if (*name == '<') { ! dstname = ++name; ! name = getqzname(name, '>'); ! if (*name != '>') ! return -1; ! dstlen = name - dstname; ! name++; ! } else { ! dstname = name; ! name = getzname(name); ! dstlen = name - dstname; /* length of DST zone name */ ! } if (dstlen < 3) return -1; if (*name != '\0' && *name != ',' && *name != ';') { diff -r -c old/private.h new/private.h *** old/private.h Mon Apr 4 11:24:32 2005 --- new/private.h Thu May 26 14:54:07 2005 *************** *** 25,30 **** --- 25,32 ---- #endif /* !defined NOID */ #endif /* !defined lint */ + #define GRANDPARENTED "Local time zone must be set--see zic manual page" + /* ** Defaults for preprocessor symbols. ** You can override these in your C compiler options, e.g. `-DHAVE_ADJTIME=0'. diff -r -c old/solar87 new/solar87 *** old/solar87 Thu Apr 21 15:04:16 2005 --- new/solar87 Thu May 26 12:42:35 2005 *************** *** 1,4 **** ! # @(#)solar87 7.3 # So much for footnotes about Saudi Arabia. # Apparent noon times below are for Riyadh; your mileage will vary. --- 1,4 ---- ! # @(#)solar87 7.4 # So much for footnotes about Saudi Arabia. # Apparent noon times below are for Riyadh; your mileage will vary. *************** *** 381,388 **** # Before and after 1987, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh87 3:07:04 - ?? 1987 ! 3:07:04 sol87 ?? 1988 ! 3:07:04 - ?? # For backward compatibility... Link Asia/Riyadh87 Mideast/Riyadh87 --- 381,388 ---- # Before and after 1987, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh87 3:07:04 - zzz 1987 ! 3:07:04 sol87 zzz 1988 ! 3:07:04 - zzz # For backward compatibility... Link Asia/Riyadh87 Mideast/Riyadh87 diff -r -c old/solar88 new/solar88 *** old/solar88 Thu Apr 21 15:04:16 2005 --- new/solar88 Thu May 26 12:42:35 2005 *************** *** 1,4 **** ! # @(#)solar88 7.3 # Apparent noon times below are for Riyadh; they're a bit off for other places. # Times were computed using formulas in the U.S. Naval Observatory's --- 1,4 ---- ! # @(#)solar88 7.4 # Apparent noon times below are for Riyadh; they're a bit off for other places. # Times were computed using formulas in the U.S. Naval Observatory's *************** *** 381,388 **** # Before and after 1988, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh88 3:07:04 - ?? 1988 ! 3:07:04 sol88 ?? 1989 ! 3:07:04 - ?? # For backward compatibility... Link Asia/Riyadh88 Mideast/Riyadh88 --- 381,388 ---- # Before and after 1988, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh88 3:07:04 - zzz 1988 ! 3:07:04 sol88 zzz 1989 ! 3:07:04 - zzz # For backward compatibility... Link Asia/Riyadh88 Mideast/Riyadh88 diff -r -c old/solar89 new/solar89 *** old/solar89 Thu Apr 21 15:04:16 2005 --- new/solar89 Thu May 26 12:42:35 2005 *************** *** 1,4 **** ! # @(#)solar89 7.4 # Apparent noon times below are for Riyadh; they're a bit off for other places. # Times were computed using a formula provided by the U. S. Naval Observatory: --- 1,4 ---- ! # @(#)solar89 7.5 # Apparent noon times below are for Riyadh; they're a bit off for other places. # Times were computed using a formula provided by the U. S. Naval Observatory: *************** *** 386,393 **** # Before and after 1989, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh89 3:07:04 - ?? 1989 ! 3:07:04 sol89 ?? 1990 ! 3:07:04 - ?? # For backward compatibility... Link Asia/Riyadh89 Mideast/Riyadh89 --- 386,393 ---- # Before and after 1989, we'll operate on local mean solar time. # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] ! Zone Asia/Riyadh89 3:07:04 - zzz 1989 ! 3:07:04 sol89 zzz 1990 ! 3:07:04 - zzz # For backward compatibility... Link Asia/Riyadh89 Mideast/Riyadh89 diff -r -c old/zdump.c new/zdump.c *** old/zdump.c Mon Apr 4 11:24:32 2005 --- new/zdump.c Thu May 26 12:48:56 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.64"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.65"; /* ** This code has been made independent of the rest of the time *************** *** 144,151 **** --- 144,153 ---- static time_t absolute_max_time; static size_t longest; static char * progname; + static int warned; static char * abbr P((struct tm * tmp)); + static void abbrok P((const char * abbr, const char * zone)); static long delta P((struct tm * newp, struct tm * oldp)); static void dumptime P((const struct tm * tmp)); static time_t hunt P((char * name, time_t lot, time_t hit)); *************** *** 191,196 **** --- 193,236 ---- } #endif /* !defined TYPECHECK */ + static void + abbrok(abbr, zone) + const char * const abbr; + const char * const zone; + { + register int i; + register const char * cp; + register char * wp; + + if (warned) + return; + cp = abbr; + wp = NULL; + while (isascii(*cp) && isalpha(*cp)) + ++cp; + if (cp - abbr == 0) + wp = _("lacks alphabetic at start"); + if (cp - abbr < 3) + wp = _("has fewer than 3 alphabetics"); + if (cp - abbr > 6) + wp = _("has more than 6 alphabetics"); + if (wp == NULL && (*cp == '+' || *cp == '-')) { + ++cp; + if (isascii(*cp) && isdigit(*cp)) + if (*cp++ == '1' && *cp >= '0' && *cp <= '4') + ++cp; + } + if (*cp != '\0') + wp = _("differs from POSIX standard"); + if (wp == NULL) + return; + (void) fflush(stdout); + (void) fprintf(stderr, + "%s: warning: zone \"%s\" abbreviation \"%s\" %s\n", + progname, zone, abbr, wp); + warned = TRUE; + } + int main(argc, argv) int argc; *************** *** 297,302 **** --- 337,343 ---- show(argv[i], now, FALSE); continue; } + warned = FALSE; t = absolute_min_time; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; *************** *** 527,532 **** --- 568,575 ---- } } (void) printf("\n"); + if (tmp != NULL && *abbr(tmp) != '\0') + abbrok(abbr(tmp), zone); } static char * diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Apr 4 11:24:32 2005 --- new/zic.c Thu May 26 14:54:07 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.122"; /* ** Regardless of the type of time_t, we do our work using this type. --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.124"; /* ** Regardless of the type of time_t, we do our work using this type. *************** *** 10,15 **** --- 10,19 ---- #include "locale.h" #include "tzfile.h" + #ifndef ZIC_MAX_ABBR_LEN_WO_WARN + #define ZIC_MAX_ABBR_LEN_WO_WARN 6 + #endif /* !defined ZIC_MAX_ABBR_LEN_WO_WARN */ + #if HAVE_SYS_STAT_H #include "sys/stat.h" #endif *************** *** 2196,2201 **** --- 2200,2240 ---- { register int i; + if (strcmp(string, GRANDPARENTED) != 0) { + register const char * cp; + register char * wp; + + /* + ** Want one to ZIC_MAX_ABBR_LEN_WO_WARN alphabetics + ** optionally followed by a + or - and a number from 1 to 14. + */ + cp = string; + wp = NULL; + while (isascii(*cp) && isalpha(*cp)) + ++cp; + if (cp - string == 0) + wp = _("time zone abbreviation lacks alphabetic at start"); + if (noise && cp - string > 3) + wp = _("time zone abbreviation has more than 3 alphabetics"); + if (cp - string > ZIC_MAX_ABBR_LEN_WO_WARN) + wp = _("time zone abbreviation has too many alphabetics"); + if (wp == NULL && (*cp == '+' || *cp == '-')) { + ++cp; + if (isascii(*cp) && isdigit(*cp)) + if (*cp++ == '1' && *cp >= '0' && *cp <= '4') + ++cp; + } + if (*cp != '\0') + wp = _("time zone abbreviation differs from POSIX standard"); + if (wp != NULL) { + wp = ecpyalloc(wp); + wp = ecatalloc(wp, " ("); + wp = ecatalloc(wp, string); + wp = ecatalloc(wp, ")"); + warning(wp); + ifree(wp); + } + } i = strlen(string) + 1; if (charcnt + i > TZ_MAX_CHARS) { error(_("too many, or too long, time zone abbreviations"));
Date: Thu, 26 May 2005 15:20:36 -0400 (EDT) From: Arthur David Olson <olsona@lecserver.nci.nih.gov> Message-ID: <200505261920.j4QJKaOH019938@lecserver.nci.nih.gov> | 4. localtime.c is changed to restrict characters in | abbreviations to [a-zA-Z0-9 :+-] You probably ought include '_' in the set (just because, and as it is certainly harmless). | and to restrict abbreviation lengths to 16 Is there any reason we need to keep insisting on a min length of 3 (and as a const in the code, rather than a #define) ? A min length of 1 seems like it would be better, if not very useful in practice (though it would allow those bizarre US military zone names), but 2 could certainly be useful. kre
BTW, I regenerated the timezone localizations, based on the latest CLDR 1.3 data. See http://www.unicode.org/cldr//data/dropbox/timezones/ We are still not complete, but are making progress. Examples: For cases like Greek there are very few explicit zone names and very few exemplar cities, so you fall back to countries and (Latin) city names: http://www.unicode.org/cldr//data/dropbox/timezones/el_timezones.html For cases like French or Finnish, there is more data, more city names, and some explicit data for some cases, such as America/Vancouver and Europe/Paris. http://www.unicode.org/cldr//data/dropbox/timezones/fr_timezones.html http://www.unicode.org/cldr//data/dropbox/timezones/fi_timezones.html http://www.unicode.org/cldr//data/dropbox/timezones/ja_timezones.html For other cases like Uzbek, we are also missing many country names, and so the only available information are the country codes. http://www.unicode.org/cldr//data/dropbox/timezones/uz_Cyrl_timezones.html Mark
On 4 Jun 2005, at 01:56, Mark Davis wrote:
BTW, I regenerated the timezone localizations, based on the latest CLDR 1.3 data. See
http://www.unicode.org/cldr//data/dropbox/timezones/
We are still not complete, but are making progress.
Unfortunately, some of the progress is in the wrong direction. :-) The en_timezones.html file contains this for the UK (Europe/London): --- 348 United Kingdom Europe/London GB-Eire; GB generic standard daylight gmt GMT-00:00/-01:00 GMT-00:00 GMT-01:00 short BT BST BDT long British Time British Standard Time British Daylight Time --- The short and long rows are completely wrong. We don't use the name British Daylight Time or the abbreviation BDT for our daylight saving time (and we don't use the term daylight saving either). We call the concept summer time, named British Summer Time, with abbreviation BST. We use Greenwich Mean Time as the name for our standard time, abbreviated as GMT. We did use the name British Standard Time for an ill-fated experiment between 1968 and 1972 where we had the clocks an hour in advance of GMT all year round. This name was no doubt chosen so the same BST abbreviation could be used for what was in effect summer time all year. The BST abbreviation for standard time is the biggest problem as it gives the wrong meaning for an abbreviation in common use, which will only cause confustion. I've never heard the name British Time used for `generic' time, whatever that might be; and if you mention BT to the average UK person they will think of our phone company: British Telecommunications. Some URLs to back this up: <http://www.dti.gov.uk/er/bankhol.htm> A UK government site with bank holiday dates, and Timetable for British Summer Time link near the bottom. <http://www.nmm.ac.uk/server/show/nav.00500300f00h> A National Maritime Museum (home of the Greenwich Observatory) page with a bit about summer time near the bottom, showing use of GMT and BST. <http://www.publications.parliament.uk/pa/ld199798/ldhansrd/vo970611/ text/70611-10.htm#70611-10_head0> The second reading debate on a Bill introduced by Lord Tanlaw which would have made UTC the UK's legal time. The second paragraph of column 965 gives the basis for GMT as the UK's legal time. The Bill failed. And of course, <http://www.srcf.ucam.org/~jsm28/british-time/>, Joseph Myers' page with all the gory UK legal detail. I noticed the BDT abbreviation in the OS X 10.4 (Tiger) Mail program and submitted a bug report to Apple (4078227). I guess they got it from this CLDR data. Where did these names and abbreviations come from? How can they get fixed? Peter Ilieve peter@aldie.co.uk
Thanks for the information. If you could file a bug at http://www.jtcsv.com/cgibin/locale-bugs?user=guest, we'd appreciate it. Ideally we need 6 names, starting with 3 full ones: generic: British Time winter: ? summer: British Summer Time All of the names have to uniquely map to a tzid to support roundtripping. That is, given a locale, if someone formats a date + tzid and then parses the result, he or she gets back exactly the same date and tzid. Thus we can't use the long name Greenwich Mean Time or the abbreviation GMT to refer to the "British Winter Time", because GMT (= Etc/GMT) is invariant (no daylight/summer time rules). We can, however, use a qualifier, like "Greenwich Mean Time (UK)" or "GMT (UK)". We also need three distinct abbreviations (if available). generic: BT winter: ? summer: BST? If an abbreviation is not specified, the fallback will be the corresponding long name. If a long name is not specified, the fallback is to a country name (if a single zone) or country-city name combination. Another twist. The timezone files that are generated are for the default language values, in this case, English. The values can actually vary by individual country. So we have to decide whether these changes should be made for all of English, or for just, say, the UK and Ireland (en_GB, en_IE). I don't see any reason for not doing it for all of English ("Summer Time" is a more meaningful term than "Daylight Savings Time" anyway), but if there are any reasons not to do that you might mention them. And including the rest of the sources you cite in the bug report would be very helpful. Mark ----- Original Message ----- From: "Peter Ilieve" <peter@aldie.co.uk> To: <tz@lecserver.nci.nih.gov> Sent: Saturday, June 04, 2005 04:32 Subject: Re: Timezone translations
On 4 Jun 2005, at 01:56, Mark Davis wrote:
BTW, I regenerated the timezone localizations, based on the latest CLDR 1.3 data. See
http://www.unicode.org/cldr//data/dropbox/timezones/
We are still not complete, but are making progress.
Unfortunately, some of the progress is in the wrong direction. :-)
The en_timezones.html file contains this for the UK (Europe/London):
--- 348 United Kingdom Europe/London GB-Eire; GB
generic standard daylight gmt GMT-00:00/-01:00 GMT-00:00 GMT-01:00 short BT BST BDT long British Time British Standard Time British Daylight Time ---
The short and long rows are completely wrong. We don't use the name British Daylight Time or the abbreviation BDT for our daylight saving time (and we don't use the term daylight saving either). We call the concept summer time, named British Summer Time, with abbreviation BST. We use Greenwich Mean Time as the name for our standard time, abbreviated as GMT. We did use the name British Standard Time for an ill-fated experiment between 1968 and 1972 where we had the clocks an hour in advance of GMT all year round. This name was no doubt chosen so the same BST abbreviation could be used for what was in effect summer time all year.
The BST abbreviation for standard time is the biggest problem as it gives the wrong meaning for an abbreviation in common use, which will only cause confustion.
I've never heard the name British Time used for `generic' time, whatever that might be; and if you mention BT to the average UK person they will think of our phone company: British Telecommunications.
Some URLs to back this up:
<http://www.dti.gov.uk/er/bankhol.htm> A UK government site with bank holiday dates, and Timetable for British Summer Time link near the bottom.
<http://www.nmm.ac.uk/server/show/nav.00500300f00h> A National Maritime Museum (home of the Greenwich Observatory) page with a bit about summer time near the bottom, showing use of GMT and BST.
<http://www.publications.parliament.uk/pa/ld199798/ldhansrd/vo970611/ text/70611-10.htm#70611-10_head0> The second reading debate on a Bill introduced by Lord Tanlaw which would have made UTC the UK's legal time. The second paragraph of column 965 gives the basis for GMT as the UK's legal time. The Bill failed.
And of course, <http://www.srcf.ucam.org/~jsm28/british-time/>, Joseph Myers' page with all the gory UK legal detail.
I noticed the BDT abbreviation in the OS X 10.4 (Tiger) Mail program and submitted a bug report to Apple (4078227). I guess they got it from this CLDR data.
Where did these names and abbreviations come from? How can they get fixed?
Peter Ilieve peter@aldie.co.uk
On 4 Jun 2005, at 17:41, Mark Davis wrote:
Thus we can't use the long name Greenwich Mean Time or the abbreviation GMT to refer to the "British Winter Time", because GMT (= Etc/GMT) is invariant (no daylight/summer time rules). We can, however, use a qualifier, like "Greenwich Mean Time (UK)" or "GMT (UK)".
You're stuffed then (to put it politely :-). I don't really understand what the CLDR is for, but if it is supposed to provide text strings that a user in a particular locale would expect for things like timezone names and abbreviations then the only acceptable things for UK users are Greenwich Mean Time / GMT and British Summer Time / BST. It's hard to argue with the Interpretation Act 1978, which specifies Greenwich Mean Time as the UK's legal time. Do you know any MPs? Maybe you could get it amended to add the " (UK)". :-) Peter Ilieve peter@aldie.co.uk
You're stuffed then (to put it politely :-).
Not at all -- there was no intent at all to have the message mean anything like that. We periodically notify this mailing list and others of releases of CLDR, and we really would like bugs filed for problems that people notice. And it is best if the people themselves file them, since they then get notified as to additional commentary on the bug, and as the bug goes through the process of getting fixed. If you don't want to do that, I can certainly file on your behalf, using the information you supplied. In this particular case, however, it is unclear what we should do; that's why I tried to spell out the issues. It would be very easy for us to change the summer time to British Summer Time, but for the winter time there is a problem, because of the ambiguity of the use of the term "GMT". Here is the problem. You fill in a calendar form for a recurring meeting, one that is to happen at "10:00 am GMT". If (a) the software maps the "GMT" to the tzid Europe/London, then the time of that meeting will be 10:00Z in the winter, and change to 09:00Z in the summer. If (b) the software maps "GMT" to Etc/GMT, then that meeting will be at 10:00Z all year round. It can't do both, and doing (a) would cause all kinds of other problems. If you (or others) have any ideas for handling this, I'd be glad to forward them. Mark ----- Original Message ----- From: "Peter Ilieve" <peter@aldie.co.uk> To: <tz@lecserver.nci.nih.gov> Sent: Saturday, June 04, 2005 10:41 Subject: Re: Timezone translations
On 4 Jun 2005, at 17:41, Mark Davis wrote:
Thus we can't use the long name Greenwich Mean Time or the abbreviation GMT to refer to the "British Winter Time", because GMT (= Etc/GMT) is invariant (no daylight/summer time rules). We can, however, use a qualifier, like "Greenwich Mean Time (UK)" or "GMT (UK)".
You're stuffed then (to put it politely :-).
I don't really understand what the CLDR is for, but if it is supposed to provide text strings that a user in a particular locale would expect for things like timezone names and abbreviations then the only acceptable things for UK users are Greenwich Mean Time / GMT and British Summer Time / BST.
It's hard to argue with the Interpretation Act 1978, which specifies Greenwich Mean Time as the UK's legal time. Do you know any MPs? Maybe you could get it amended to add the " (UK)". :-)
Peter Ilieve peter@aldie.co.uk
Here is the problem. You fill in a calendar form for a recurring meeting, one that is to happen at "10:00 am GMT". If (a) the software maps the "GMT" to the tzid Europe/London, then the time of that meeting will be 10:00Z in the winter, and change to 09:00Z in the summer. If (b) the software maps "GMT" to Etc/GMT, then that meeting will be at 10:00Z all year round. It can't do both, and doing (a) would cause all kinds of other problems.
If you (or others) have any ideas for handling this, I'd be glad to forward them.
I used to work for a company that provided a logistics information system. We exchanged electronic messages with all sorts of enterprises worldwide. The rule for chronological data was basically, if you want to communicate a date/time to us, you must send it either as UTC (or local time with UTC offset specified), or as a local time along with the name of the place where the event occurred. (As an aside, I must mention that the place name had to be validated. If you sent the name "Springfield, U.S.A.", it would be rejected for ambiguity.) We used the tz database, with other supporting data, to convert between local time and UTC at each location. The results were generally acceptable. If that solution can't be adapted for your situation, then maybe you'll need to do some user education. Users tend to assume that what works for them will work for everyone. For example, users in New York want to say "Eastern Time" and let the computer do everything else. They don't care that users in Indianapolis also want to say "Eastern Time", but diverge from New York in the summer (until 2006, anyway). Users in Toronto who specify "Eastern Time" are in synch with New York for the present, but there may have been times in the past, or come times in the future, when the DST/standard time switch is on different dates in Canada and the U.S. Users in Sydney may also want to say "Eastern Time", but it means something totally different. One possible way of dealing with the ambiguity is to let users specify "Eastern Time", but then pop up a disambiguation window that explains the difference among the various meanings of that phrase, and asks them to pick the right one. Obviously it would get annoying to see that window pop up all the time. There could be mitigating work-arounds. One possibility is to let the user pick a default time zone for that computer or application. Another is to provide unique, unambiguous time zone names like "Eastern Time - New York", "Eastern Time - Indianapolis", etc. as alternatives to the ambiguous names. -- Gwillim Law
<<On Sat, 4 Jun 2005 20:33:12 -0400, "Gwillim Law" <RLAW@nc.rr.com> said:
Another is to provide unique, unambiguous time zone names like "Eastern Time - New York", "Eastern Time - Indianapolis", etc. as alternatives to the ambiguous names.
Indeed, the description file included with the tz database does exactly that. In FreeBSD we provide a CUI timezone selector interface called "tzsetup" that is used for configuring the system's default timezone, which generates its user interface dynamically from /usr/share/misc/iso3166 and /usr/share/zoneinfo/zone.tab; if we wanted to localize this application (there has been no demand thus far), we would probably do so by localizing these two data files. (I think this is somewhat orthogonal to the localization of timezone abbreviations, which only exist in a few locales to begin with. Indeed, I would argue that it is nearly always an error to localize abbreviations for zones other than those used in that locale.) -GAWollman
On Sat, Jun 04, 2005 at 04:04:46PM -0700, Mark Davis wrote:
Here is the problem. You fill in a calendar form for a recurring meeting, one that is to happen at "10:00 am GMT". If (a) the software maps the "GMT" to the tzid Europe/London, then the time of that meeting will be 10:00Z in the winter, and change to 09:00Z in the summer. If (b) the software maps "GMT" to Etc/GMT, then that meeting will be at 10:00Z all year round. It can't do both, and doing (a) would cause all kinds of other problems.
If you (or others) have any ideas for handling this, I'd be glad to forward them.
For this specific case, the right thing to do is discourage the old historical (pre-1972) usage of GMT as "universal time", and promote the proper modern term UTC instead. Said a different way, GMT is the time that Britan observes during the winter; UTC is the so-called "universal" time that most countries use as a reference for their civil time (adjusted by the local zone offset); use of GMT to mean UTC is wrong (though apparently still quite common). --Ken Pizzini
While UTC may be the better term, it is far less well known. Mark ----- Original Message ----- From: "Ken Pizzini" <tz.@explicate.org> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Sunday, June 05, 2005 01:20 Subject: Re: Timezone translations
On Sat, Jun 04, 2005 at 04:04:46PM -0700, Mark Davis wrote:
Here is the problem. You fill in a calendar form for a recurring meeting, one that is to happen at "10:00 am GMT". If (a) the software maps the "GMT" to the tzid Europe/London, then the time of that meeting will be 10:00Z in the winter, and change to 09:00Z in the summer. If (b) the software maps "GMT" to Etc/GMT, then that meeting will be at 10:00Z all year round. It can't do both, and doing (a) would cause all kinds of other problems.
If you (or others) have any ideas for handling this, I'd be glad to forward them.
For this specific case, the right thing to do is discourage the old historical (pre-1972) usage of GMT as "universal time", and promote the proper modern term UTC instead. Said a different way, GMT is the time that Britan observes during the winter; UTC is the so-called "universal" time that most countries use as a reference for their civil time (adjusted by the local zone offset); use of GMT to mean UTC is wrong (though apparently still quite common).
--Ken Pizzini
On 5 Jun 2005, at 00:04, Mark Davis wrote:
In this particular case, however, it is unclear what we should do; that's why I tried to spell out the issues. It would be very easy for us to change the summer time to British Summer Time, but for the winter time there is a problem, because of the ambiguity of the use of the term "GMT".
But lots of the abbreviations are ambiguous. When I first got involved with this sort of stuff, back in the days of 4.1c bsd or so, I remember the surprise of discovering Bering Straits Time for example. It's hard to avoid this ambiguity when you've only got three letters, and one of them is almost bound to be T. It's the concept of "can't use the long name Greenwich Mean Time or the abbreviation GMT" (from your previous mail) that I'm struggling to understand. I've been on the timezone mailing list for a long time, and I like to think I've contributed something towards documenting the convoluted history of UK summer time changes. During that time I've seen Arthur Olson and Paul Eggert work to try to make sense of the chaotic human messiness of timezone naming, and try and catch up with the capricious changes that politicians make to the clocks. There's no notion of "can't" in this. If someone pops up and produces credible evidence that some group of people call their timzeone XYZ, then XYZ goes in the database. It reflects what people use in their everyday lives. The CLDR doesn't seem to be like that. Your talk of roundtripping, parsing and so on implies some higher purpose. I wrote higher as the result is that I "can't" call my local winter time by the only name by which I have known it ever since I can remember. Take the famous man on the Clapham omnibus, now armed with a laptop and cadging Internet access from a nearby insecure WiFi access point while his bus is stuck in the traffic. He wants the dates in his emails to look right, and that means having GMT in the winter. If you tell him that he can't have that because some bunch of programmers who he's never heard of say it will upset the internal workings of some software he's never heard of either he is unlikely to be impressed. If you ask him if he would mind having "GMT (UK)" instead to fix this he is likely to give a dusty answer.
Here is the problem. [calendar scheduling details snipped]
That is indeed a problem. I don't have an answer to it. I suspect the answer will involve using UTC times and a timezone name like Europe/ London, with the Europe/London taken from the preferences set for the particular application or from the user's default settings. Going back to your suggestion that I file a bug report, I visited that URL and it reminded me why I didn't try and file a bug before. It has a warning that I must read the Data Formats and Filing Bug Reports before submitting. OK, I thought, maybe I can skip the data formats one and just read the one about filing, but no, that page not only repeats the instruction to read the data formats page but adds more instructions to consult the comparison and by-type charts. I'm sorry, but I'm not going to do all that, especially when you've told me in advance that the only terms I would use for UK non-summer time will be rejected. What's the point? Finally, I'll repeat the question from my first mail about this, which I forgot to add to my last mail: where did the current data for Europe/London in the en_timezones.html come from? Peter Ilieve peter@aldie.co.uk
I'm sorry, but I'm not going to do all that, especially when you've told me in advance that the only terms I would use for UK non-summer time will be rejected. What's the point?
The reason why we have such cautions is that we have found that many people don't provide enough information in the reports for us to do anything reasonable with it -- and often don't respond to follow-up questions, so we try to provide enough background information so that that doesn't happen. Since you are not interested in filing the bug, I filed one with the information you provided, at http://www.jtcsv.com/cgibin/locale-bugs?findid=738 Our goal is to match customary usage in the countries covered, but I was trying to give you a sense of the options that we have. If "GMT" means something ambiguous, then we have to find a way to resolve that ambiguity. As I mentioned, one alternative is that in the UK locale (en_GM), "GMT" means Europe/London, whereas in other English-speaking locales it means Etc/GMT. That would let your fellow in the traffic jam see what he expects. But there are downsides to that approach. One thought I had while reading this discussion is that we may need to explore trying to refine our recommendations for usage to allow us to relax the roundtripping requirement for cases where the ambiguity is probably acceptable. The datetime format strings used to provide a pattern for formatting, with the following letters being used: z: for short wall (generic) (eg PT) zz: for long wall (eg Pacific Time) zzz: for the short specific (eg PST) zzzz: for the full specific (eg Pacific Standard Time). Z: for GMT format (eg GMT-08:00) ZZ: for RFC 822 format (eg -0800) Thus where the purpose is to pick a tzid from a menu or in formatted/parseable strings -- and especially for recurring meetings -- we would recommend using the generic form, and keep the requirement for uniqueness of names within a language. On the other hand, for formatting a specific time with the specific standard/daylight (winter/summer) strings, allow collisions in the translations *if* the results would be the same in modern time. Thus as long as "GMT" meant a constant GTM+00:00, it would be ok if there was a collision in translated names between Europe/London and Etc/GMT (or between Africa/Casablanca and Etc/GMT, etc.). In the end, it is up to the CLDR committee to try to come up with a solution, but suggestions are welcome.
Finally, I'll repeat the question from my first mail about this, which I forgot to add to my last mail: where did the current data for Europe/London in the en_timezones.html come from?
I would have to wade back through all the checkins to see where it came from. Frankly, since it looks like it is wrong anyway, it is not a particularly good use of time. Mark ----- Original Message ----- From: "Peter Ilieve" <peter@aldie.co.uk> To: <tz@lecserver.nci.nih.gov> Sent: Sunday, June 05, 2005 04:21 Subject: Re: Timezone translations
On 5 Jun 2005, at 00:04, Mark Davis wrote:
In this particular case, however, it is unclear what we should do; that's why I tried to spell out the issues. It would be very easy for us to change the summer time to British Summer Time, but for the winter time there is a problem, because of the ambiguity of the use of the term "GMT".
But lots of the abbreviations are ambiguous. When I first got involved with this sort of stuff, back in the days of 4.1c bsd or so, I remember the surprise of discovering Bering Straits Time for example. It's hard to avoid this ambiguity when you've only got three letters, and one of them is almost bound to be T.
It's the concept of "can't use the long name Greenwich Mean Time or the abbreviation GMT" (from your previous mail) that I'm struggling to understand. I've been on the timezone mailing list for a long time, and I like to think I've contributed something towards documenting the convoluted history of UK summer time changes. During that time I've seen Arthur Olson and Paul Eggert work to try to make sense of the chaotic human messiness of timezone naming, and try and catch up with the capricious changes that politicians make to the clocks. There's no notion of "can't" in this. If someone pops up and produces credible evidence that some group of people call their timzeone XYZ, then XYZ goes in the database. It reflects what people use in their everyday lives.
The CLDR doesn't seem to be like that. Your talk of roundtripping, parsing and so on implies some higher purpose. I wrote higher as the result is that I "can't" call my local winter time by the only name by which I have known it ever since I can remember.
Take the famous man on the Clapham omnibus, now armed with a laptop and cadging Internet access from a nearby insecure WiFi access point while his bus is stuck in the traffic. He wants the dates in his emails to look right, and that means having GMT in the winter. If you tell him that he can't have that because some bunch of programmers who he's never heard of say it will upset the internal workings of some software he's never heard of either he is unlikely to be impressed. If you ask him if he would mind having "GMT (UK)" instead to fix this he is likely to give a dusty answer.
Here is the problem. [calendar scheduling details snipped]
That is indeed a problem. I don't have an answer to it. I suspect the answer will involve using UTC times and a timezone name like Europe/ London, with the Europe/London taken from the preferences set for the particular application or from the user's default settings.
Going back to your suggestion that I file a bug report, I visited that URL and it reminded me why I didn't try and file a bug before. It has a warning that I must read the Data Formats and Filing Bug Reports before submitting. OK, I thought, maybe I can skip the data formats one and just read the one about filing, but no, that page not only repeats the instruction to read the data formats page but adds more instructions to consult the comparison and by-type charts.
I'm sorry, but I'm not going to do all that, especially when you've told me in advance that the only terms I would use for UK non-summer time will be rejected. What's the point?
Finally, I'll repeat the question from my first mail about this, which I forgot to add to my last mail: where did the current data for Europe/London in the en_timezones.html come from?
Peter Ilieve peter@aldie.co.uk
On 6 Jun 2005, at 01:23, Mark Davis wrote:
Finally, I'll repeat the question from my first mail about this, which I forgot to add to my last mail: where did the current data for Europe/London in the en_timezones.html come from?
I would have to wade back through all the checkins to see where it came from. Frankly, since it looks like it is wrong anyway, it is not a particularly good use of time.
I disagree. There is a set of slides (in PowerPoint format, so much for open standards) giving an overview of CLDR linked from <http:// www.unicode.org/cldr/>. Slides 14 and 15 describe a vetting process, which strongly encourages references to external sources and mentions consultation with contacts in the countries concerned. How did this completely bogus Europe/London data for English get through that process? It looks to me as though someone just took the data for America/New_York and did s/Eastern/British/g;s/E/B/g. That's the simplest explanation of how it ended up with BT and BDT, terms never used in the UK, and with BST as the term for the wrong sort of time. Can you demonstrate otherwise? If I find that the tiny subset of CLDR data that I know about is so wrong why should I trust any of the rest of it without some explanation of why the bit I know about is wrong? Peter Ilieve peter@aldie.co.uk
in the countries concerned. How did this completely bogus Europe/London data for English get through that process?
We seeded the project with a set of data that hadn't gone through this process yet, so it hadn't gone through the same level of vetting. We have put out 2 releases since this project was adopted by the Unicode consortium (it was previously sponsored by the Linux Application Development Environment (aka LADE) Workgroup of the Free Standards Group's OpenI18N (formerly known as Linux Internationalization Initiative or Li18nux) team. I gather from a previous message that you knew of this problem, but were scared off (or simply annoyed) by our bug form; too bad, because we could have fixed the problem earlier. We have to fix the bug form if it is keeping knowledgeable people from reporting problems. We are faced with a huge amount of data, and part of our process has been to try to get tools in place to make it easier to people both to submit data and to vet it. To that end, we've been working on a tool (http://www.unicode.org/cgi-bin/cldr-survey/) that lets us get access to data more easily. For example, en_GB is here: http://www.unicode.org/cgi-bin/cldr-survey?_=en_GB
If I find that the tiny subset of CLDR data that I know about is so wrong why should I trust any of the rest of it without some explanation of why the bit I know about is wrong?
Interestingly, it is often more difficult for us to get good vetting of data for English countries than it is for more 'exotic' ones like Finnish or Farsi. Mark ----- Original Message ----- From: "Peter Ilieve" <peter@aldie.co.uk> To: <tz@lecserver.nci.nih.gov> Sent: Monday, June 06, 2005 01:07 Subject: Re: Timezone translations
On 6 Jun 2005, at 01:23, Mark Davis wrote:
Finally, I'll repeat the question from my first mail about this, which I forgot to add to my last mail: where did the current data for Europe/London in the en_timezones.html come from?
I would have to wade back through all the checkins to see where it came from. Frankly, since it looks like it is wrong anyway, it is not a particularly good use of time.
I disagree. There is a set of slides (in PowerPoint format, so much for open standards) giving an overview of CLDR linked from <http:// www.unicode.org/cldr/>. Slides 14 and 15 describe a vetting process, which strongly encourages references to external sources and mentions consultation with contacts in the countries concerned. How did this completely bogus Europe/London data for English get through that process?
It looks to me as though someone just took the data for America/New_York and did s/Eastern/British/g;s/E/B/g. That's the simplest explanation of how it ended up with BT and BDT, terms never used in the UK, and with BST as the term for the wrong sort of time. Can you demonstrate otherwise?
If I find that the tiny subset of CLDR data that I know about is so wrong why should I trust any of the rest of it without some explanation of why the bit I know about is wrong?
Peter Ilieve peter@aldie.co.uk
On 7 Jun 2005, at 01:54, Mark Davis wrote:
We seeded the project with a set of data that hadn't gone through this process yet, so it hadn't gone through the same level of vetting.
So you did take America/New_York and do s/Eastern/British/g;s/E/B/g. :-) Why pick on just the UK? Why not do that for say Europe/Helsinki, inventing Finnish Daylight Time, or indeed all the en translations? As you suggest below (and I've snipped), surely the Finns would fight their way through your bug reporting system to complain.
We have put out 2 releases since this project was adopted by the Unicode consortium
This 1.3 release is the first with the timezone data though. Was there really a need to rush stuff through unvetted to meet some sort of deadline? With your Unicode Consortium hat on I'm sure you wouldn't have accepted this sort of thing for new additions to Unicode. Folk like Michael Everson need to produce fully researched proposals for that.
We are faced with a huge amount of data, and part of our process has been to try to get tools in place to make it easier to people both to submit data and to vet it. To that end, we've been working on a tool (http://www.unicode.org/cgi-bin/cldr-survey/) that lets us get access to data more easily. For example, en_GB is here: http://www.unicode.org/cgi-bin/cldr-survey?_=en_GB
OK, lets look at that en_GB page. It starts by saying: Vetting is now CLOSED for CLDR 1.3. Thank you! That may be fair enough as 1.3 is now released, but it goes on: To submit vetting information with the survey tool, you will need an account. You should get information on your account from your CLDR contact. If you don't have an account, you can view all the data, but cannot submit. You really aren't doing yourself any favours with stuff like this. If you want feedback and bug reports please think of things from the point of view of people who might submit such stuff. They know about a bit of data, that's why they are trying to correct it, but they probably wouldn't know a CLDR contact from Adam. As I see it you have two problems. The first is a data quality problem with bogus stuff like British Daylight Time and British Time. This is a technical problem that can get fixed. With luck you will change your bug reporting and this survey tool to be less intimidating and you will get more feedback. The second problem is this business of your uniqueness requirements resulting in CLDR trying to tell users that they can't use names that they have used since childhood for what seems to them to be a simple concept like time. I don't know how you fix that, but I'm sure that in any argument about this the users will win. Folk in the UK, me included, aren't going to stop using the names GMT or BST any time soon. Maybe if our government legislates for it we might, but attempts to legislate for UTC have already failed so I doubt that any government will lift the lid off that can of worms for a long while. Peter Ilieve peter@aldie.co.uk
Mark Davis said:
Ideally we need 6 names, starting with 3 full ones:
generic: British Time
Unless you want to be targeted by many Northern Irish, I wouldn't do that. There is no generic name for the time used in the UK.
winter: ?
Greenwich Mean Time
summer: British Summer Time
Thus we can't use the long name Greenwich Mean Time or the abbreviation GMT to refer to the "British Winter Time",
You can't *NOT* use the long name Greenwich Mean Time or the abbreviation GMT to refer to it. Because that is what it is called. Full stop. Selah. End of story. Are you also going to declare that New York can't use EST? If so, then you are away with the fairies.
We also need three distinct abbreviations (if available).
generic: BT
GMT/BST
winter: ?
GMT
summer: BST?
BST
If an abbreviation is not specified, the fallback will be the corresponding long name. If a long name is not specified, the fallback is to a country name (if a single zone)
Will you get this right?
Another twist. The timezone files that are generated are for the default language values, in this case, English. The values can actually vary by individual country. So we have to decide whether these changes should be made for all of English, or for just, say, the UK and Ireland (en_GB, en_IE).
I don't know if Ireland uses the term GMT and BST, or something else. Probably the latter.
I don't see any reason for not doing it for all of English ("Summer Time" is a more meaningful term than "Daylight Savings Time" anyway), but if there are any reasons not to do that you might mention them.
How about the fact that many English-speaking people [*] use the term "Daylight Savings Time"? [*] Accepting American as a dialect of English for this purpose. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
Unless you want to be targeted by many Northern Irish, I wouldn't do that. There is no generic name for the time used in the UK.
If we supply nothing, then it will fall back to the last field of the TZID ("London"). Showing a blank menu item is not really an option ;-)
Are you also going to declare that New York can't use EST?
No. I don't see how what I said would give you that impression.
I don't see any reason for not doing it for all of English ("Summer ... How about the fact that many English-speaking people [*] use the term "Daylight Savings Time"?
[*] Accepting American as a dialect of English for this purpose.
What I was referring to was specifically the name for Europe/London. Nothing that I wrote was about the English names for the US timezones. Mark ----- Original Message ----- From: "Clive D.W. Feather" <clive@demon.net> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Peter Ilieve" <peter@aldie.co.uk>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 05, 2005 14:38 Subject: Re: Timezone translations
Mark Davis said:
Ideally we need 6 names, starting with 3 full ones:
generic: British Time
Unless you want to be targeted by many Northern Irish, I wouldn't do that. There is no generic name for the time used in the UK.
winter: ?
Greenwich Mean Time
summer: British Summer Time
Thus we can't use the long name Greenwich Mean Time or the abbreviation GMT to refer to the "British Winter Time",
You can't *NOT* use the long name Greenwich Mean Time or the abbreviation GMT to refer to it. Because that is what it is called.
Full stop. Selah. End of story.
Are you also going to declare that New York can't use EST? If so, then you are away with the fairies.
We also need three distinct abbreviations (if available).
generic: BT
GMT/BST
winter: ?
GMT
summer: BST?
BST
If an abbreviation is not specified, the fallback will be the corresponding long name. If a long name is not specified, the fallback is to a country name (if a single zone)
Will you get this right?
Another twist. The timezone files that are generated are for the default language values, in this case, English. The values can actually vary by individual country. So we have to decide whether these changes should be made for all of English, or for just, say, the UK and Ireland (en_GB, en_IE).
I don't know if Ireland uses the term GMT and BST, or something else. Probably the latter.
I don't see any reason for not doing it for all of English ("Summer Time" is a more meaningful term than "Daylight Savings Time" anyway), but if there are any reasons not to do that you might mention them.
How about the fact that many English-speaking people [*] use the term "Daylight Savings Time"?
[*] Accepting American as a dialect of English for this purpose.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
Date: Sun, 5 Jun 2005 17:36:33 -0700 From: "Mark Davis" <mark.davis@jtcsv.com> Message-ID: <005301c56a2f$ca8a36f0$6501a8c0@sanjose.ibm.com> | > Are you also going to declare that New York can't use EST? | No. I don't see how what I said would give you that impression. But "EST" is ambiguous, how can you possibly use it for your purposes? Aside from the (several) different meanings in north America, it's also the name of (both) the summer and standard timezones in eastern Australia (all 4 (or is it more) different versions of them). The first thing that you should note is that you do not need to distinguish (in user input) the difference between summer and standard timezones, you can always work that out from the date, assuming you know the locality. People use either "local time" (either the local time where they are, which is most common, or sometimes "local time at location X"), or they use UTC (whether they call it that or GMT). No-one expresses the time in terms of what it would be if only it was not summer right now, or if summer time didn't apply. Similarly, a meeting at 4pm every Monday is at 4pm standard time in winter, and 4pm summer time in summer, whether the meeting schedule was set in summer or winter. Second, the only half way reliable way to work out what time zone applies is to find out what location the time is supposed to apply in, that is, if someone wants to schedule a meeting at 4pm, you need to know 4pm in which city. Given that there's no longer any ambiguity at all, and just a combination of programming, and database, to convert to universal time so it can be shared with others (and represented in whatever timezone is convenient for them, which should either be in numeric form (+1000, -0700, or something) or in terms of a location. Asking for any form of time zone name input is just asking for trouble. Outputting one where you intend its use to be anything more than a comfort blanket for the user is just plain silly. Even as just friendly info, zone names help rather than hinder only in those locations (countries really, though Europe might count as a country for this) where there are multiple timezones - in others, the time is just the time, and has no name at all. kre
On 6 Jun 2005, at 03:57, Robert Elz wrote:
Even as just friendly info, zone names help rather than hinder only in those locations (countries really, though Europe might count as a country for this) where there are multiple timezones - in others, the time is just the time, and has no name at all.
Spot on. That's why I struggled to understand the concept of generic time, let alone put a name to it. As Clive Feather writes elsewhere, there is no generic name for the time used in the UK. Peter Ilieve peter@aldie.co.uk
But "EST" is ambiguous, how can you possibly use it for your purposes?
As I tried to say, we *can* have different translations for different locales. So we could have: en_US: America/New York <=> EST en_AU: Australia/Sydney <=> EST en: (the default English locale, with unspecified country) Europe/Tallinn <=> EST What we couldn't have is two conflicting values in the same locale, such as: en_US: America/New York <=> EST Australia/Sydney <=> EST
Similarly, a meeting at 4pm every Monday is at 4pm standard time in winter, and 4pm summer time in summer, whether the meeting schedule was set in summer or winter.
That is clearly true. And that's what we mean by 'generic' (or wall time). And if everyone in the meeting shares the same implicit timezone and thus references that particular wall time, that is not an issue. Or even if we are setting up a recurring telecon meeting with people from many different timezones, as long as I can communicate that I want wall time according to tzid X. The whole issue is around how to identify the tzids that are being used, in this scenario and others.
Second, the only half way reliable way to work out what time zone applies is to find out what location the time is supposed to apply in, that is, if someone wants to schedule a meeting at 4pm, you need to know 4pm in which city. ... Even as just friendly info, zone names help rather than hinder only in those locations (countries really, though Europe might count as a country for this) where there are multiple timezones - in others, the time is just the time, and has no name at all.
Also understood. As I'm sure you know, we cannot assume that the user's locale determines the timezone. I could have en_US as my locale, but that doesn't tell me the timezone; I might actually be working in Paris for a while. One of our tasks is to provide data to allow users -- of any language -- to pick timezones. For that we need to be able to show a list, where a user can pick the timezone from any of the world's timezones, and the list should be localized to be what makes sense in that user's locale. In that list, we need the names to be unique; having two different tzids with the same name, and without any other qualification would not let the user make a choice. For this generic name, what we have in CLDR is provision -- for any given locale -- for either showing a translation of the country (+city if the country alone is not sufficient), or for having an explicit override to some other customary form. Now, it may well be, that there is no customary name for "British Time". In that case, the correct action on our part may be to simply delete the override, and fall back to the default, which I think would be "United Kingdom (London)" A second task is formatting/parsing a string with a date and or time, including the zone. For that, as I mentioned earlier, we have in the past provided several options. Thus given a locale we could format/parse "10:13 PST" or "10:13 PDT". Currently we require that all of the labels -- if supplied -- also be unique, but as I said in my message of Sunday, June 05, 2005 17:23 (my time), one thing I can bring up for the CLDR committee to decide is whether we should relax that requirement, so that for a given locale we could allow name collisions -- where it doesn't matter which tzid is generated. That is predicated on the fact that if I parse "10:13 GMT", it doesn't matter whether GMT maps to Etc/GMT or whether it maps to Europe/London; I get the same results. Mark ----- Original Message ----- From: "Robert Elz" <kre@munnari.OZ.AU> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Clive D.W. Feather" <clive@demon.net>; "Peter Ilieve" <peter@aldie.co.uk>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 05, 2005 19:57 Subject: Re: Timezone translations Date: Sun, 5 Jun 2005 17:36:33 -0700 From: "Mark Davis" <mark.davis@jtcsv.com> Message-ID: <005301c56a2f$ca8a36f0$6501a8c0@sanjose.ibm.com> | > Are you also going to declare that New York can't use EST? | No. I don't see how what I said would give you that impression. But "EST" is ambiguous, how can you possibly use it for your purposes? Aside from the (several) different meanings in north America, it's also the name of (both) the summer and standard timezones in eastern Australia (all 4 (or is it more) different versions of them). The first thing that you should note is that you do not need to distinguish (in user input) the difference between summer and standard timezones, you can always work that out from the date, assuming you know the locality. People use either "local time" (either the local time where they are, which is most common, or sometimes "local time at location X"), or they use UTC (whether they call it that or GMT). No-one expresses the time in terms of what it would be if only it was not summer right now, or if summer time didn't apply. Similarly, a meeting at 4pm every Monday is at 4pm standard time in winter, and 4pm summer time in summer, whether the meeting schedule was set in summer or winter. Second, the only half way reliable way to work out what time zone applies is to find out what location the time is supposed to apply in, that is, if someone wants to schedule a meeting at 4pm, you need to know 4pm in which city. Given that there's no longer any ambiguity at all, and just a combination of programming, and database, to convert to universal time so it can be shared with others (and represented in whatever timezone is convenient for them, which should either be in numeric form (+1000, -0700, or something) or in terms of a location. Asking for any form of time zone name input is just asking for trouble. Outputting one where you intend its use to be anything more than a comfort blanket for the user is just plain silly. Even as just friendly info, zone names help rather than hinder only in those locations (countries really, though Europe might count as a country for this) where there are multiple timezones - in others, the time is just the time, and has no name at all. kre
On Mon, Jun 06, 2005 at 05:31:16PM -0700, Mark Davis wrote:
What we couldn't have is two conflicting values in the same locale, such as:
en_US: America/New York <=> EST Australia/Sydney <=> EST ... Also understood. As I'm sure you know, we cannot assume that the user's locale determines the timezone. I could have en_US as my locale, but that doesn't tell me the timezone; I might actually be working in Paris for a while.
How are things supposed to be handled if you are using en_US for your locale, and you are working in Sydney for a while? --Ken Pizzini
How are things supposed to be handled if you are using en_US for your locale, and you are working in Sydney for a while?
I'm not quite sure what kind of scenario you are thinking of, so I'm not sure how to answer. For example, suppose I am on a business trip in Sydney using a program that is, accepting a calendar invitation from an American in New York, with tzid America/New York and the date 2005-01-12T18:00:00, and my locale is set to en_US, and my timezone is set to Austrialia/Sydney. In many calendar programs you can see the datetime in both your timezone and the originators. Assuming that we make no other changes*, if if the program chose to use a format that showed the timezone abbreviation, and you have set your locale to en_US, then you would see "January 12, 2005 10:00 EST" for the originator's zone. * As I said below in that message;
Currently we require that all of the labels -- if supplied -- also be unique, but as I said in my message of Sunday, June 05, 2005 17:23 (my time), one thing I can bring up for the CLDR committee to decide is whether ...
Mark ----- Original Message ----- From: "Ken Pizzini" <tz.@explicate.org> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Monday, June 06, 2005 18:24 Subject: Re: Timezone translations
On Mon, Jun 06, 2005 at 05:31:16PM -0700, Mark Davis wrote:
What we couldn't have is two conflicting values in the same locale, such as:
en_US: America/New York <=> EST Australia/Sydney <=> EST ... Also understood. As I'm sure you know, we cannot assume that the user's locale determines the timezone. I could have en_US as my locale, but that doesn't tell me the timezone; I might actually be working in Paris for a while.
How are things supposed to be handled if you are using en_US for your locale, and you are working in Sydney for a while?
--Ken Pizzini
On Mon, Jun 06, 2005 at 07:06:48PM -0700, Mark Davis wrote:
How are things supposed to be handled if you are using en_US for your locale, and you are working in Sydney for a while?
I'm not quite sure what kind of scenario you are thinking of, so I'm not sure how to answer.
What I was attempting to get at, is that I'm completely failing to see why it would be okay to have ambiguity inter-locale, yet have it be a problem intra-locale. If EST has to be unique within en_US, then when a New Yorker travels to Sydney there is an ambiguity just as big as if EST were allowed to have multiple meanings in en_US in the first place. If the ambiguity can be resolved in one situation, then it should be able to be resolved in both (as far as I can see). In the example you gave, the answer seemed to be, in essence, "in TZ=America/New_York, EST means UTC -0800, and in TZ=America/Sydney, EST in the austral summer means UTC +1100, and data interchange is always normalized to UTC or UTC with offset", which seems like a perfectly reasonable solution to me, and is completely independent of what locale is in effect, and means that en_US should be able to handle many meanings for EST, with the TZ associated with a given timestamp resolving which EST is meant.
* As I said below in that message;
Currently we require that all of the labels -- if supplied -- also be unique, but as I said in my message of Sunday, June 05, 2005 17:23 (my time), one thing I can bring up for the CLDR committee to decide is whether ...
Okay then, as of yesterday you've conceded doubt about CLDR's current stance on the topic. I think there is still room for discussion about how best to drive home to the CLDR folk that any uniqueness requirement in this realm is a bad idea. Official zone names and abbreviations are what they are, and I doubt there'd be any luck in trying to convince the various governments and societies involved to adopt a globally rational system. (TZIDs, however, can be expected to be unique, as that is the whole reason that these otherwise non-standard and somewhat ad-hoc identifiers were created.) And to make sure I'm clear on the point, I'll emphasize: non-uniqueness applies to "long form" names as well as the short abbreviations --- scheduling something at "14:45 Eastern Standard Time" is almost as meaningless as scheduling it for "14:45 EST". (I.e., is that Eastern Australia, Eastern United States, or Eastern Canada? The last two are currently equivalent, but there is no reason to expect that they always will be; there have been times in the past where at least the transition rules were different.) The nature of the ambiguity is the same, and the need to resolve the ambiguity by means outside of the locale definitions are just as necessary. --Ken Pizzini
Date: Mon, 6 Jun 2005 17:31:16 -0700 From: "Mark Davis" <mark.davis@jtcsv.com> Message-ID: <020e01c56af8$37c072c0$6501a8c0@sanjose.ibm.com> | That is clearly true. And that's what we mean by 'generic' (or wall time). | And if everyone in the meeting shares the same implicit timezone and thus | references that particular wall time, that is not an issue. Of course. The question is how you should disambiguate when the precondition is not true. | Or even if we | are setting up a recurring telecon meeting with people from many different | timezones, as long as I can communicate that I want wall time according to | tzid X. No, that is exactly what you should not attempt to do. It just doesn't work, it isn't human friendly, and you get to suffer interminable lectures from the people on this list. | The whole issue is around how to identify the tzids that are being | used, in this scenario and others. Yes, and the way to avoid it is to just not attempt to do it. Your later comments make it clear that you misinterpreted my suggestion from my earlier message, so this time I will attempt to be clearer. (And any blame for misinterpretation is mine, lots of people manage to fail to understand me, so the fault is obviously mine). | Also understood. As I'm sure you know, we cannot assume that the user's | locale determines the timezone. No. I didn't mean that kind of locale (as in the posix type magic word "locale"). I meant it as in the form you'd find it in the dictionary (normal English dictionary, no specific technical terms). That is, a rough synonym for "location". I am not suggesting that you attempt to automate, or guess, the particular local time to apply, I'm suggesting that you ask the user "in which city does that local time apply". That is, the user can say "we will have this meeting every week, at 4pm, Paris (France) time." Then you have no more ambiguity at all (or not unless the French government goes absurdly even unimaginably, wild with its time definitions). It makes no difference for this what the user's Posix Locale is (except perhaps how "Paris" and "France" might be spelled), nor where the user happens to be geographically or network topologically located when the meeting time is set (though one of those may be used to suggest a default local time to apply). Just give up on using any kind of timezone name for any algorithmic purpose (when appropriate, they can sometimes, but only sometimes, be used in user presentation). I know this is hard to accept for Americans, who are used to dealing with times being specified as "4pm Pacific", or "7pm Eastern" (etc), and the common frequent use of names for the timezones, rather than specifying them as "the time in Los Angeles" or "the time in New York City" - and for humans, usually, it works just fine - as people just know when you say "Eastern" you mean the time in New York, or Washington, or whatever, and not the time in some bizarre county in Indiana. But most of the world doesn't work like that, time zone names are much less used (even in Australia - in the US, a TV network would advertise a live event as being at some time Eastern, or some other time Pacific, in Australia it would be advertised as some time (Eastern, aka Sydney, being mostly assumed in Australia...) or at some other time in Perth (or sometimes, in Western Australia). "Western Standard/Summer Time", or even just "Western" just doesn't get used. The only name names that you can reliably use are GMT, UTC, and UT, all of which mean +0000 (always) (and they all mean the same thing for any normal human purpose) | A second task is formatting/parsing a string with a date and or time, | including the zone. Forget it. Even given a posix locale you cannot do that. The impossibility of interpreting anything from the abbreviations is why the mail standards now say to use numeric timezones always (even though the old ones are still permitted for backwards compatability) - and why your mail, my mail, and I think everyone else's mail these days, have numeric timezone offsets in the Date: header (and even in Received headers), not alphabetic ones. Just don't even try for this one. kre
Mark Davis said:
Unless you want to be targeted by many Northern Irish, I wouldn't do that. There is no generic name for the time used in the UK. If we supply nothing, then it will fall back to the last field of the TZID ("London"). Showing a blank menu item is not really an option ;-)
<shrug> There is no generic name for the time used in the UK.
Are you also going to declare that New York can't use EST? No. I don't see how what I said would give you that impression.
If I can't use the name I normally use for my local time, why should you be entitled to? After all, lots of places use the term "EST". Ask the Estonians.
I don't see any reason for not doing it for all of English ("Summer ... How about the fact that many English-speaking people [*] use the term "Daylight Savings Time"?
[*] Accepting American as a dialect of English for this purpose.
What I was referring to was specifically the name for Europe/London. Nothing that I wrote was about the English names for the US timezones.
You wrote "all of English". I may consider Americans to be wrong about this, but they refer to "Daylight Savings Time" when asking me what happens in the UK. However, if you wish to pick a single term for this purpose, then "Summer Time" is best. My personal preference, though, would be for you to stop trying to hammer round pegs into this trapezoidal hole. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
How about the fact that many English-speaking people [*] use the term "Daylight Savings Time"?
You wrote "all of English". I may consider Americans to be wrong about this, but they refer to "Daylight Savings Time" when asking me what happens in the UK.
Two separate points on collateral matters: In previous discussions on this list, the consensus has been that "Daylight Saving Time" (as opposed to "Savings") is correct. A few Web pages that confirm this are http://webexhibits.org/daylightsaving/b.html, http://en.wikipedia.org/wiki/Daylight_saving_time, and http://geography.about.com/cs/daylightsavings/a/dst.htm. I didn't find any that disagreed. I am American. I always use "daylight saving time" in my own speech. I would feel uncomfortable using "summer time" in oral discourse to mean the same thing. Why? Because it sounds exactly like "summertime", which refers to vacation and warm weather, not clock time. I don't think of "summer time" as wrong, but as British usage, like "lift" vs. "elevator" or 25/12/2005 vs. 12/25/2005. -- Gwillim Law
Webster's (an American English dictionary; Collegiate edition) says: * daylight saving time: time usually one hour ahead of standard time -- called also daylight time. * savings: money put by. * summer time: chiefly British: daylight saving time. * summertime: the summer season or a period like summer. * wintertime: the season of winter. * winter time: [not in the dictionary]. Interestingly, I found in a British dictionary from Penguin Books: * summer-time: system whereby clocks are put one hour ahead in summer; summer. Yes, with a hyphen and meaning both, i.e. the American summer time & summertime. Factoid for translators: In the Dutch language (spoken in The Netherlands and in Belgium - Flanders) we call DST "zomertijd" and standard time "wintertijd". Oscar van Vlijmen 2005-06-06
Date: Mon, 6 Jun 2005 11:30:43 -0400 From: "Gwillim Law" <RLAW@nc.rr.com> Message-ID: <000e01c56aac$b44495c0$0200a8c0@statoids4qizor> | I am American. I always use "daylight saving time" in my own speech. I | would feel uncomfortable using "summer time" in oral discourse to mean the | same thing. Why? Because it sounds exactly like "summertime", which refers | to vacation and warm weather, not clock time. I doubt that there's any real chance for ambiguity there, if someone gives a time as "7pm summer time", they pretty clearly don't mean some random 7pm during the period of December to March (approx), (or June-August in other parts of the world) - they are (for whatever reason) distinguishing the time from standard time. Similarly, if you tell your kids you'll take them to the beach in summertime (just "summer" would do really, unless you're a lyricist and need a rhyme) they aren't expected to understand that as the clocks move forward an hour they will find themselves transported to a sandy location. It is more just what you're used to. Beyond that, if you really want "something saving time", then it should really be "Electricity Saving Time", as that's what the time shift was originally (and still sometimes used) to save. It's absurd to believe that changing the clocks is going to have any effect on the amount of daylight that exists, or for that matter, that daylight is something that can be saved. Which is why most of the world calls it summer time, as in the time that applies during (roughly) the summer months. | I don't think of "summer | time" as wrong, but as British usage, like "lift" vs. "elevator" or Yes, just different. Though I think I'd call it "non-American" usage, since it really applies in Britain, and almost everywhere else (to the extent it isn't overwhelmed by exported US mass media) Except for ... | 25/12/2005 vs. 12/25/2005. where the US usage is just too bizarre to even contemplate (I mean, who would design a numeric format with the least significant digits in the *middle*) kre
On Mon, Jun 06, 2005 at 05:30:04AM +0100, "Clive D.W. Feather" <clive@demon.net> wrote:
My personal preference, though, would be for you to stop trying to hammer round pegs into this trapezoidal hole.
I faintly remember that this discussion went in a similar direction the first time the CLDR came up here, and the suggestions were ignored. The principial problem is indeed that the CLDR wants to enforce unrealistic terms and rules, and now it runs into the problems that this approach creates. Any "standard" that does this will likely fall into disuse because people won't accept them due to their incompatibility with reality. The people behind the CLDR should _really_ re-think the whole process and their goals. There is considerable knowledge about these issues on this list (me excluded), and I don't think dismissing that is a good idea. From: Peter Ilieve <peter@aldie.co.uk>
I disagree. There is a set of slides (in PowerPoint format, so much for open standards
Lots of details about the CLDR project sound strange. It doesn't look well-researched or well-designed. Now would be a greta time to change that. IMnsHO. -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
I don't recall ignoring or dismissing information from this group the first time CLDR came up (correct me on that if I'm wrong). If we thought that the people on this list didn't have a lot to offer, we wouldn't bother trying to get feedback. And it may well be that we need to rethink some of the way that we are doing things regarding timezones or other areas -- CLDR has not been going on that long, and there are clearly areas for improvement. If you have suggestions, you can either let me know directly, or file bugs on areas. Mark ----- Original Message ----- From: "Marc Lehmann" <schmorp@schmorp.de> To: <tz@lecserver.nci.nih.gov> Cc: "Mark Davis" <mark.davis@jtcsv.com> Sent: Monday, June 06, 2005 15:04 Subject: Re: Timezone translations On Mon, Jun 06, 2005 at 05:30:04AM +0100, "Clive D.W. Feather" <clive@demon.net> wrote:
My personal preference, though, would be for you to stop trying to hammer round pegs into this trapezoidal hole.
I faintly remember that this discussion went in a similar direction the first time the CLDR came up here, and the suggestions were ignored. The principial problem is indeed that the CLDR wants to enforce unrealistic terms and rules, and now it runs into the problems that this approach creates. Any "standard" that does this will likely fall into disuse because people won't accept them due to their incompatibility with reality. The people behind the CLDR should _really_ re-think the whole process and their goals. There is considerable knowledge about these issues on this list (me excluded), and I don't think dismissing that is a good idea. From: Peter Ilieve <peter@aldie.co.uk>
I disagree. There is a set of slides (in PowerPoint format, so much for open standards
Lots of details about the CLDR project sound strange. It doesn't look well-researched or well-designed. Now would be a greta time to change that. IMnsHO. -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
"Clive D.W. Feather" <clive@demon.net> writes:
I don't know if Ireland uses the term GMT and BST, or something else. Probably the latter.
Our information is that the Republic of Ireland uses "GMT" and "IST" (short for "Irish Summer Time"). An anonymous tz contributor verified this with the Secretary of the Irish Department of Justice. A couple of other points. First, the tz database uses "BDST" for "British Double Summer Time", most recently observed in 1947. Second, the abbreviation "BST" is ambiguous even in Britain: for time stamps from 1968-10-27 to 1971-10-31 it means "British Standard Time", not "British Summer Time". This British Standard Time is one hour ahead of UTC but it is standard time, not summer time. This sort of thing may all sound fairly baroque, but if it happened in the past it's possible it'll happen in the future, and a comprehensive time zone translation scheme should be able to support it.
Thanks for the information. We already had a bug on Ireland; I'll add the information to that, and file another bug for the double-summer time. Mark ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: <tz@lecserver.nci.nih.gov> Cc: "Mark Davis" <mark.davis@jtcsv.com> Sent: Monday, June 06, 2005 16:47 Subject: Re: Timezone translations
"Clive D.W. Feather" <clive@demon.net> writes:
I don't know if Ireland uses the term GMT and BST, or something else. Probably the latter.
Our information is that the Republic of Ireland uses "GMT" and "IST" (short for "Irish Summer Time"). An anonymous tz contributor verified this with the Secretary of the Irish Department of Justice.
A couple of other points. First, the tz database uses "BDST" for "British Double Summer Time", most recently observed in 1947. Second, the abbreviation "BST" is ambiguous even in Britain: for time stamps from 1968-10-27 to 1971-10-31 it means "British Standard Time", not "British Summer Time". This British Standard Time is one hour ahead of UTC but it is standard time, not summer time.
This sort of thing may all sound fairly baroque, but if it happened in the past it's possible it'll happen in the future, and a comprehensive time zone translation scheme should be able to support it.
Paul Eggert said:
I don't know if Ireland uses the term GMT and BST, or something else. Probably the latter. Our information is that the Republic of Ireland uses "GMT" and "IST" (short for "Irish Summer Time"). An anonymous tz contributor verified this with the Secretary of the Irish Department of Justice.
Fine. Of course, that is ambiguous with Israeli Standard Time.
This sort of thing may all sound fairly baroque, but if it happened in the past it's possible it'll happen in the future, and a comprehensive time zone translation scheme should be able to support it.
Indeed. I think the most important message our CLDR colleagues need to take from this is that this stuff is *not* neat and can't be made so. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
On Tue, 7 Jun 2005, Clive D.W. Feather wrote:
Our information is that the Republic of Ireland uses "GMT" and "IST" (short for "Irish Summer Time"). An anonymous tz contributor verified this with the Secretary of the Irish Department of Justice.
Fine. Of course, that is ambiguous with Israeli Standard Time.
And also with Indian Standard Time. ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-5617723 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim@cse.huji.ac.il
participants (12)
-
Arthur David Olson -
Clive D.W. Feather -
Ephraim Silverberg -
Garrett Wollman -
Gwillim Law -
Ken Pizzini -
Marc Lehmann -
Mark Davis -
Oscar van Vlijmen -
Paul Eggert -
Peter Ilieve -
Robert Elz