- tz - lists.iana.org

FW: Web pages using recent versions of the tz database
by Olson, Arthur David (NIH/NCI) May 26, 2005

May 26, 2005

Paul/Kate is not on the time zone mailing list; direct replies appropriately. (And...what are the odds on "Thank you in advance for your time" being intentionally humorous?) --ado From: paul [mailto:paul@world-stay.com] Sent: Wednesday, May 25, 2005 9:43 AM To: tz(a)lecserver.nci.nih.gov Subject: Web pages using recent versions of the tz database I thought you may be interested in placing a link on your site to our home page as we use the tz database to display times around the world. We provide information about the time in locations all over the world, including daylight maps, sunrise and sunset times and free clocks that can be added to a web page by simply pasting a few lines of HTML code. Please have a look at the site http://time.world-stay.com/en/ , any feedback is always gratefully received. Thank you in advance for your time, Kate http://time.world-stay.com/

1 0

Web pages using recent versions of the tz database
by paul May 25, 2005

May 25, 2005

I thought you may be interested in placing a link on your site to our home page as we use the tz database to display times around the world. We provide information about the time in locations all over the world, including daylight maps, sunrise and sunset times and free clocks that can be added to a web page by simply pasting a few lines of HTML code. Please have a look at the site http://time.world-stay.com/en/ , any feedback is always gratefully received. Thank you in advance for your time, Kate http://time.world-stay.com/

1 0

zic warnings about odd time zone abbreviations
by Arthur David Olson May 24, 2005

May 24, 2005

Here are changes to zic.c to produce warnings about non-POSIX time zone abbreviations. I've also included changes to the "solar" files to use a POSIX-compliant "zzz" abbreviation (rather than the non-compliant "??") for the zone whose name we don't know. --ado ------- Makefile ------- *** /tmp/geta10569 Tue May 24 13:21:00 2005 --- /tmp/getb10569 Tue May 24 13:21:00 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 \ ------- zic.c ------- *** /tmp/geta10785 Tue May 24 13:32:28 2005 --- /tmp/getb10785 Tue May 24 13:32:29 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.123"; /* ** Regardless of the type of time_t, we do our work using this type. *************** *** 10,15 **** --- 10,21 ---- #include "locale.h" #include "tzfile.h" + #define GRANDPARENTED "Local time zone must be set--see zic manual page" + + #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 **** --- 2202,2242 ---- { 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")); ------- solar87 ------- *** /tmp/geta10623 Tue May 24 13:21:32 2005 --- /tmp/getb10623 Tue May 24 13:21:32 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 ------- solar88 ------- *** /tmp/geta10642 Tue May 24 13:21:36 2005 --- /tmp/getb10642 Tue May 24 13:21:36 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 ------- solar89 ------- *** /tmp/geta10661 Tue May 24 13:21:44 2005 --- /tmp/getb10661 Tue May 24 13:21:44 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

2 1

64-bit zic -s
by Robbin Kawabata May 23, 2005

May 23, 2005

The new 64-bit time zic has the -s flag removed. Can you give some details about its removal - do machines that have signed time_t and unsigned time_t no longer need to share timezone files? Is -s no longer needed to pass SVVS? Also, is there any reason the -s could not be supported by the new 64-bit zic? We usually give a 1-year warning before we remove functionality, so we might add this option back into the 64-bit zic locally (with a note we plan to remove it in the next release). thanks, Robbin

1 0

64-bit work
by Olson, Arthur David (NIH/NCI) May 23, 2005

May 23, 2005

Since the 5-byte (rather than 8-byte) extension to the time zone binary data file format went over with an overwhelming thud, my current thinking is to stick revert to the 8-byte approach. The name of the game would be to produce binary files with: 1. data with 32-bit time values through 2037 (for use by old systems) 2. data with 64-bit time values for "historic" years 3. a newline enclosed, POSIX-conforming TZ-environment-variable-style string telling what to do in years beyond those covered by 2 above. There are a few places (Cairo, Godthab, Chile) that can't be represented by POSIX-conforming strings; for these we'd punt to the "write 400 years worth of data and work modulo 400" approach (leaving off the trailing TZ string). --ado

1 0

Re: Maintainer of timezone/zdump.c
by Paul Eggert May 21, 2005

May 21, 2005

"Earl C. Ruby III" <earl(a)switchmanagement.com> writes: > I am trying to locate the maintainer of the timezone/zdump.c program. tz(a)elsie.nci.nih.gov is it. I'm removing the other CC's. > I am running several dozen SuSE Linux systems and all of them show the same > (incorrect) results when zdump is run for an "Etc/UTC+X" timezone. The sign convention for Etc/UTC+X is purposely backwards from what you expected. > I've written a set of Perl timezone conversion routines which pull > data from zdump. I've added a patch to my software which works > around this problem with zdump, but I feel that zdump itself should > be fixed to deal with this. As far as I can see, zdump is correct, and so is zic. My advice is to stay away from those TZ=Etc/* settings. For details, please see the long comment in the etcetera file in the tz distribution.

2 1

Re: TZ environment variable
by Olson, Arthur David (NIH/NCI) May 20, 2005

May 20, 2005

If the TZ environment variable needs to be checked for mischief-making time zone abbreviations, the same check needs to be applied to values derived from time zone files (since, at least on some systems, users can create arbitrary files and arrange for them to be used with an appropriate TZ setting.) --ado

9 11

Mongolia 2005 (3)
by Oscar van Vlijmen May 20, 2005

May 20, 2005

From: Embassy of Mongolia, Washington, D.C. - Tourism http://www.mongolianembassy.us/eng_tourism/tourism.php "Time Difference Mongolia is 8 hours ahead of GMT in winter and 9 hours ahead in summer. The three western aimags of Mongolia , Uvs, Bayan Ulgii and Khovd are one hour behind Ulaanbaatar and the rest of Mongolia." I found nothing of importance yet on: http://www.open-government.mn/ Oscar van Vlijmen 2005-05-20

1 0

Re: TZ environment variable
by Robbin Kawabata May 19, 2005

May 19, 2005

There was some discussion about localized tznames. SunOS currently doesn't support localized tzname's. If we were to implement it, we would probably take the approach of i18n messages. We could create message catalogs for Olson timezone tznames, which contain translated tznames for the locales. A message-id could be created, perhaps by concatenating the timezone name with the tzname (for example, "America/Los_Angeles_PST"). The message-id could be passed to dcgettext(), which would return the localized tzname according to the locale specified by LC_TIME. We might use a new specifier in strftime() (which would call dcgettext()) to return the localized tzname or the original tzname if no localized tzname exists. We would keep the values of TZ and tzname[] as elements from the portable character set. The TZ environment variable is inherited by applications. By default applications start in the C locale. If a time function is called before setlocale() is done (or if the application does not call setlocale()), the time function could fail if TZ is composed of invalid characters for the C locale. Also, if TZ or tzname[] is composed of multibyte characters, and the application changes locales, it could invalidate those characters. Robbin

2 1

RE: Mongolia has two time zones GMT +7 and GMT +8 (DST GMT +8 and DST GMT +9)
by Bill Bonnett May 19, 2005

May 19, 2005

This is what I got from the U.S. Embassy in Ulaanbaatar: All of Mongolia is on one time zone. It is 13 hours ahead of Washington, D.C. or +8 GMT. Mongolia does observe daylight savings time. Ulaanbaatar (and Irkukst, Russia) share a time zone entry, with daylight savings time option, on Windows XP. _____ From: Risto Nykänen [mailto:ristonykanen@luukku.com] Sent: Monday, May 16, 2005 5:38 PM To: Contacts(a)abdicate.net Subject: Mongolia has two time zones GMT +7 and GMT +8 (DST GMT +8 and DST GMT +9) See next link: http://www.miat.com/frame.php?page=travel_information http://www.travelmongolia.org/ Risto P.S. GMT +9 (DST GMT +10) not anylonger in use.

1 0