- tz - lists.iana.org

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

Mongolia 2005 (2)
by Oscar van Vlijmen May 18, 2005

May 18, 2005

Further research seems to indicate that the situation in Mongolia is even more complicated. See for instance a very short article plus reader comments on: <http://ubpost.mongolnews.mn/index.php?subaction=showcomments&id=1111634894& archive=&start_from=&ucat=1&> The UB Post is Mongolias independent weekly news bulletin. The article, dated 23 Mar 2005, says: "Mongolia will observe daylight savings time on March 26. Clocks will be moved forward one hour at 2:00am" A reader comment notes that parliament has decided that there are now 4 time zones: OLGII in the west, on UTC+7 ULAT, most of the country, on UTC+8 ..., a couple of aimags in the east, on UTC+9 SUKH, the Sukhbaatar aimag, on UTC+8.5 The SUKH time zone is new. Oscar van Vlijmen 2005-05-18

1 0

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

May 18, 2005

To aid the discussion of the TZ environment variable, here's a list of the time zone abbreviations that currently show up in binary time zone files if you do a "make install". (I'll put in a vote for changing the mixed-case "ChST" to a mono-case "CHST".) --ado ?? ACT ADT AFT AMT ANT AOT APT ART AST AWT AZT BDT BMT BNT BOT BRT BST BTT CAT CCT CDT CET CGT CIT CJT CKT CLT CMT COT CPT CST CUT CVT CWT CXT DMT EAT ECT EDT EET EGT EIT EPT EST EWT FJT FKT FMT FNT GET GFT GMT GST GYT HDT HKT HMT HPT HST HWT ICT IDT IMT IOT IST JMT JST KDT KGT KMT KST LKT LMT LRT LST MDT MET MHT MMT MOT MPT MSD MSK MST MUT MVT MWT MYT NCT NDT NET NFT NMT NPT NRT NST NUT NWT PDT PET PGT PHT PKT PMT PNT PPT PST PWT PYT QMT RET RMT SBT SCT SGT SMT SRT SST TFT TJT TKT TMT TOT TPT TRT TVT UCT UTC UYT UZT VET VUT WAT WET WFT WGT WIT WMT WST YDT YPT YST YWT zzz ACST ADDT ADMT AHDT AHST AKDT AKST AKTT ALMT AMST ANAT AQTT ARST ASHT AZOT AZST BAKT BDST BEAT BORT BOST BRST BURT CANT CAST CAWT CDDT CEMT CEST CGST CHAT CHDT CHOT ChST CLST COST CVST DACT DAVT DDUT DUST EAST EDDT EEST EGST EHDT FFMT FJST FKST FNST FORT FRUT GALT GAMT GBGT GEST GHST GILT HADT HAST HKST HOVT IDDT IHST IRDT IRKT IRST ISST JAVT KART KAST KGST KIZT KOST KRAT KUYT KWAT LHST LINT LONT MADT MAGT MALT MART MAWT MDDT MDST MEST MOST NCST NDDT NEGT NEST NOVT NZDT NZMT NZST OMST ORAT PDDT PEST PETT PHOT PHST PKST PMDT PMST PONT PPMT PYST QYZT ROTT SAKT SAMT SAST SDMT SHET SJMT SLST SVET SWAT SYOT TAHT TAST TBIT TBMT TOST TRST TRUT ULAT URAT URUT UYST UZST VLAT VOST VUST WAKT WART WAST WEMT WEST WGST YAKT YAPT YDDT YEKT YERT AKTST ALMST ANAST AQTST ASHST AZOMT AZOST BAKST BEAUT CHADT CHAST CHOST CKHST DUSST EASST FRUST GMT+1 GMT+2 GMT+3 GMT+4 GMT+5 GMT+6 GMT+7 GMT+8 GMT+9 GMT-1 GMT-2 GMT-3 GMT-4 GMT-5 GMT-6 GMT-7 GMT-8 GMT-9 HOVST IRKST KIZST KRAST KUYST MADMT MADST MAGST MALST NOVST OMSST ORAST PETST QYZST SAKST SAMST SHEST SVEST TASST TBIST ULAST URAST UYHST VLAST WARST YAKST YEKST YERST BORTST GMT+10 GMT+11 GMT+12 GMT-10 GMT-11 GMT-12 GMT-13 GMT-14 VLASST Local time zone must be set--see zic manual page

3 2

[07]
by retornoviral May 17, 2005

May 17, 2005

1 0

Mongolia 2005
by Oscar van Vlijmen May 16, 2005

May 16, 2005

Several sources say Mongolia has only 2 time zones with DST. The TZ asia file says 3 time zones. http://www.travelmongolia.org/travel.mongolia/travel.info.html reads: " 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. " MIAT Mongolian Airlines (http://www.miat.com/frame.php?page=travel_information ) also speak of 2 time zones, as does the usually well informed worldtimeserver.com Does anybody have more evidence on the real situation? Oscar van Vlijmen 2005-05-16

1 0

Indiana
by Garrett Wollman May 16, 2005

May 16, 2005

According to press reports I've seen elsewhere, the governor of Indiana signed the bill putting the entire state on DST effective next year. The bill also requires the governor to petition USDOT to relocate the ET/CT boundary, although the reports I've seen were a bit unclear as to where the new boundary would be, if it is even specified in the bill. So I guess at a minimum the database should be updated to show America/Indiana/* on "US" rules starting 2006 Jan 1. -GAWollman

1 0

Time-Keeping at Sea [from Mark Brader]
by Paul Eggert May 15, 2005

May 15, 2005

[Forwarded from Mark Brader. Please note that he is not on the mailing list; replies should be directed accordingly.] From: msb(a)vex.net (Mark Brader) Subject: Time-Keeping at Sea To: eggert(a)twinsun.com Date: Sun, 15 May 2005 00:52:33 -0400 (EDT) Please forward this to the tz mailing list. I am not on the list; people should direct replies accordingly. Your "australasia" file has this from Gwillim Law (2000-01-03): # An Anglo-French Conference on Time-Keeping at Sea (June, 1917) agreed that # legal time on the high seas would be zone time ... A while back I emailed Gwillim to ask about his source for this statement. At the time he didn't remeber, but later he wrote back and told me that it was Howse's "Greenwich Time and the Longitude". Gwillim kindly transcribed the passage from Howse, saving me from finding where my copy is: | In June 1917, therefore, an Anglo-French Conference on Timekeeping at Sea | assembled in London. This recommended that the zone-time system should be | used at sea, clock changes required by changes of longitude being made | preferably in one-hour steps. This recommendation was immediately adopted by | British and French ships, both naval and mercantile. Ships of most other | nations soon followed suit so that, by a few years after the war, zone time | was kept at sea, certainly by almost all naval ships and by many non-naval | ships as well. Nevertheless, up to the Second World War, the old practice of | changing ship's time at midday prevailed in many independent merchant | ships. So if this is correct, the conference said nothing at all about *legal* time; they only recommended a practice. It also isn't clear from this passage whether the recommendation was for the change to happen when the specific meridian was actually crossed, or whether it was okay to do it at a convenient time so long as you did it in one-hour steps. (On the cruise ships I've been on, time zone changes were always done overnight.) It would be interesting to find the conference proceedings and see how the conclusion was actually expressed, and to know whether there actually is such a thing as legal time for some or all ships in international waters. -- Mark Brader | "Debugging had to be discovered. I can remember Toronto | the exact instant when I realized that a large part msb(a)vex.net | of my life... was going to be spent in finding | mistakes in my own programs." -- Maurice Wilkes

1 0

FW: Kazakhstan has really two time zones
by Bill Bonnett May 12, 2005

May 12, 2005

I got this email from a wonderful helper. According to the embassy in the UK Kazakhstan only has 2 time zones, but like all info, it doesnt say WHERE the dividing line is _____ From: Risto Nykänen [mailto:ristonykanen@luukku.com] Sent: Tuesday, May 10, 2005 7:50 AM To: Contacts(a)abdicate.net Subject: Kazakhstan has really two time zones Hi, why do you not update information and show two times for Kazakhstan. See the next link: http://www.kazakhstanembassy.org.uk/cgi-bin/index/55 Risto from Helsinki P.S. Your map is also good, I like it and it put me to think about.

1 0

Re: TZ environment variable
by Paul Eggert May 10, 2005

May 10, 2005

matthew green <mrg(a)eterna.com.au> writes: > i think it must be lowered to at least 2 - i use "TZ=GB" in a script > somewhere... But we're talking about the length of the time zone abbreviation (e.g., "GMT" or "BST"), which is distinct from the length of the TZ string itself. Another check, which Garrett Wollman alluded to, is that the GMT offset should be "sane". For example, it's reasonable to reject settings like TZ="XXX9999999999". However, that leaves the issue of what is "sane". For example, Solaris 8 supports a wide range of "sane" offsets: $ date -u; TZ=XXX24:59:59 date; TZ=XXX444444 date Tue May 10 03:51:24 GMT 2005 Mon May 9 02:51:25 XXX 2005 Fri Aug 27 15:51:24 XXX 1954 but this has been tightened up in Solaris 10: $ date -u; TZ=XXX24:59:59 date; TZ=XXX444444 date Tue May 10 03:50:45 GMT 2005 Mon May 9 02:50:46 XXX 2005 Tue May 10 03:50:45 GMT 2005 I suspect this is for reasons similar to what Garrett Wollman mentioned. POSIX requires support only for UTC offsets in the range -24:59:59 through +24:59:59. (The implied daylight-saving UTC offset can be as high as +25:59:59.) The GNU C library supports only the POSIX range. I don't know the range that Solaris 10 supports.

2 1

Re: Back-of-the-envelope cost of extra data :-)
by Robbin Kawabata May 9, 2005

May 9, 2005

Amending my previous email of 5/3/05 (where I said either method is OK), our preference is the algorithmic approach. Here are some comparisons (using the smaller 5-byte time storage proposed 5/9/05 by ado). The 400-year method requires in a larger timezone file (was 1K, now 6K). localtime() requires 3K/5K (32/64 bit) more memory per process for the state struct. There is more setup processing to initialize 400-years of the ats[] table. It requires about .8MB more hard disk space for the total zoneinfo directory. All processes encounter the overhead, but most processes would not make use of it. The performance for 64-bit transitions is probably better, as it is table-driven. The algorithmic approach requires a smaller timezone file than the 400-year approach. Some number of extra bytes are needed to store the variables to be used by the algorithm (and more space needed for a small 64-bit transition table, if one is used). There is a little setup for initialization of variables that would be used by the algorithm (and more setup for the small 64-bit transition table, if one is used). Additional hard disk space is minimal (or somewhat less than the 400-year file if a small 64-bit transition table is used). Performance for 64-bit transitions (past the 64-bit transition table if one is used) would probably not be as good as the 400-year cycle approach. We prefer the algorithmic method because it requires less overhead with disk space, process memory space, and setup processing time. We feel the possible slower performance for 64-bit transitions is acceptable since most applications won't use 64-bit transitions. Robbin

1 0

Re: Back-of-the-envelope cost of extra data :-)
by Arthur David Olson May 9, 2005

May 9, 2005

One way to reduce data file growth is to store just 5 bytes of time_t values rather than 8. Since 32 bits buys about 70 years of time on each side of 1970, 40 bits buys about 256 times 70 or about 17920 years of time on each side of 1970. There will be a need to change the file format in the future (the Y20K problem). Recall that the eight-bit files resulted in a "du" report value of 1709. With the changes attached below in place, we get... Script started on Mon May 09 11:02:55 2005 du lecserver$ du -s -k tz/tmp/etc/zoneinfo tzexp/tmp/etc/zoneinfo 489 tz/tmp/etc/zoneinfo 1281 tzexp/tmp/etc/zoneinfo lecserver$ exit script done on Mon May 09 11:03:07 2005 ...meaning that about 35% of the increase has been eliminated. --ado ------- tzfile.5 ------- *** /tmp/geta29273 Mon May 9 11:01:02 2005 --- /tmp/getb29273 Mon May 9 11:01:02 2005 *************** *** 137,145 **** For version-2-format time zone files, the above header and data is followed by a second header and data, identical in format except that ! eight bytes are used for each transition time or leap second time. .SH SEE ALSO newctime(3) ! .\" @(#)tzfile.5 7.13 .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson (arthur_david_olson(a)nih.gov) --- 137,145 ---- For version-2-format time zone files, the above header and data is followed by a second header and data, identical in format except that ! five bytes are used for each transition time or leap second time. .SH SEE ALSO newctime(3) ! .\" @(#)tzfile.5 7.14 .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson (arthur_david_olson(a)nih.gov) ------- tzfile.h ------- *** /tmp/geta29292 Mon May 9 11:01:15 2005 --- /tmp/getb29292 Mon May 9 11:01:15 2005 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char tzfilehid[] = "@(#)tzfile.h 7.19"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char tzfilehid[] = "@(#)tzfile.h 7.20"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 87,93 **** /* ** If tzh_version is '2' or greater, the above is followed by a second instance ** of tzhead and a second instance of the data in which each coded transition ! ** time uses 8 rather than 4 chars. */ /* --- 87,93 ---- /* ** If tzh_version is '2' or greater, the above is followed by a second instance ** of tzhead and a second instance of the data in which each coded transition ! ** time uses 5 rather than 4 chars. */ /* ------- zic.c ------- *** /tmp/geta29311 Mon May 9 11:01:25 2005 --- /tmp/getb29311 Mon May 9 11:01:25 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.127"; #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.128"; #include "private.h" #include "locale.h" *************** *** 99,105 **** static void associate P((void)); static int ciequal P((const char * ap, const char * bp)); static void convert P((long val, char * buf)); ! static void convert64 P((zic_t val, char * buf)); static void dolink P((const char * fromfile, const char * tofile)); static void doabbr P((char * abbr, const char * format, const char * letters, int isdst)); --- 99,105 ---- static void associate P((void)); static int ciequal P((const char * ap, const char * bp)); static void convert P((long val, char * buf)); ! static void convert40 P((zic_t val, char * buf)); static void dolink P((const char * fromfile, const char * tofile)); static void doabbr P((char * abbr, const char * format, const char * letters, int isdst)); *************** *** 128,134 **** static long oadd P((long t1, long t2)); static void outzone P((const struct zone * zp, int ntzones)); static void puttzcode P((long code, FILE * fp)); ! static void puttzcode64 P((zic_t code, FILE * fp)); static int rcomp P((const void * leftp, const void * rightp)); static zic_t rpytime P((const struct rule * rp, int wantedy)); static void rulesub P((struct rule * rp, --- 128,134 ---- static long oadd P((long t1, long t2)); static void outzone P((const struct zone * zp, int ntzones)); static void puttzcode P((long code, FILE * fp)); ! static void puttzcode40 P((zic_t code, FILE * fp)); static int rcomp P((const void * leftp, const void * rightp)); static zic_t rpytime P((const struct rule * rp, int wantedy)); static void rulesub P((struct rule * rp, *************** *** 1397,1403 **** } static void ! convert64(val, buf) const zic_t val; char * const buf; { --- 1397,1403 ---- } static void ! convert40(val, buf) const zic_t val; char * const buf; { *************** *** 1404,1410 **** register int i; register int shift; ! for (i = 0, shift = 56; i < 8; ++i, shift -= 8) buf[i] = val >> shift; } --- 1404,1410 ---- register int i; register int shift; ! for (i = 0, shift = 32; i < 5; ++i, shift -= 8) buf[i] = val >> shift; } *************** *** 1420,1432 **** } static void ! puttzcode64(val, fp) const zic_t val; FILE * const fp; { ! char buf[8]; ! convert64(val, buf); (void) fwrite((void *) buf, (size_t) sizeof buf, (size_t) 1, fp); } --- 1420,1432 ---- } static void ! puttzcode40(val, fp) const zic_t val; FILE * const fp; { ! char buf[5]; ! convert40(val, buf); (void) fwrite((void *) buf, (size_t) sizeof buf, (size_t) 1, fp); } *************** *** 1603,1609 **** for (i = thistimei; i < thistimelim; ++i) if (pass == 1) puttzcode((long) ats[i], fp); ! else puttzcode64(ats[i], fp); if (thistimecnt > 0) (void) fwrite((void *) &types[thistimei], (size_t) sizeof types[0], --- 1603,1609 ---- for (i = thistimei; i < thistimelim; ++i) if (pass == 1) puttzcode((long) ats[i], fp); ! else puttzcode40(ats[i], fp); if (thistimecnt > 0) (void) fwrite((void *) &types[thistimei], (size_t) sizeof types[0], *************** *** 1638,1645 **** todo = tadd(trans[i], -gmtoffs[j]); } else todo = trans[i]; if (pass == 1) ! puttzcode(todo, fp); ! else puttzcode64(todo, fp); puttzcode(corr[i], fp); } for (i = 0; i < typecnt; ++i) --- 1638,1645 ---- todo = tadd(trans[i], -gmtoffs[j]); } else todo = trans[i]; if (pass == 1) ! puttzcode((long) todo, fp); ! else puttzcode40(todo, fp); puttzcode(corr[i], fp); } for (i = 0; i < typecnt; ++i) ------- localtime.c ------- *** /tmp/geta29330 Mon May 9 11:01:36 2005 --- /tmp/getb29330 Mon May 9 11:01:36 2005 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.92"; #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 */ *************** *** 125,131 **** */ static long detzcode P((const char * codep)); ! static time_t detzcode64 P((const char * codep)); static const char * getzname P((const char * strp)); static const char * getnum P((const char * strp, int * nump, int min, int max)); --- 125,131 ---- */ static long detzcode P((const char * codep)); ! static time_t detzcode40 P((const char * codep)); static const char * getzname P((const char * strp)); static const char * getnum P((const char * strp, int * nump, int min, int max)); *************** *** 225,231 **** } static time_t ! detzcode64(codep) const char * const codep; { register signed64_t result; --- 225,231 ---- } static time_t ! detzcode40(codep) const char * const codep; { register signed64_t result; *************** *** 232,238 **** register int i; result = (codep[0] & 0x80) ? ~0L : 0L; ! for (i = 0; i < 8; ++i) result = (result << 8) | (codep[i] & 0xff); return (time_t) result; } --- 232,238 ---- register int i; result = (codep[0] & 0x80) ? ~0L : 0L; ! for (i = 0; i < 5; ++i) result = (result << 8) | (codep[i] & 0xff); return (time_t) result; } *************** *** 343,349 **** nread = read(fid, u.buf, sizeof u.buf); if (close(fid) < 0 || nread <= 0) return -1; ! for (stored = 4; stored <= 8; stored *= 2) { int ttisstdcnt; int ttisgmtcnt; --- 343,349 ---- nread = read(fid, u.buf, sizeof u.buf); if (close(fid) < 0 || nread <= 0) return -1; ! for (stored = 4; stored <= 5; ++stored) { int ttisstdcnt; int ttisgmtcnt; *************** *** 372,378 **** return -1; for (i = 0; i < sp->timecnt; ++i) { sp->ats[i] = (stored == 4) ? ! detzcode(p) : detzcode64(p); p += stored; } for (i = 0; i < sp->timecnt; ++i) { --- 372,378 ---- return -1; for (i = 0; i < sp->timecnt; ++i) { sp->ats[i] = (stored == 4) ? ! detzcode(p) : detzcode40(p); p += stored; } for (i = 0; i < sp->timecnt; ++i) { *************** *** 402,408 **** lsisp = &sp->lsis[i]; lsisp->ls_trans = (stored == 4) ? ! detzcode(p) : detzcode64(p); p += stored; lsisp->ls_corr = detzcode(p); p += 4; --- 402,408 ---- lsisp = &sp->lsis[i]; lsisp->ls_trans = (stored == 4) ? ! detzcode(p) : detzcode40(p); p += stored; lsisp->ls_corr = detzcode(p); p += 4;

2 1

Re: TZ environment variable
by kennykb＠crd.ge.com May 9, 2005

May 9, 2005

olsona(a)dc37a.nci.nih.gov said: > 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.) I always personally considered *that* a bit of a security bug. In the Tcl implementation, I restricted named timezones to combinations of alphanumerics, slashes and underscores, without a leading slash; in this way, paths from the root or from '..' couldn't be constructed. It's arguable that it's a feature rather than a bug, but I decided to err on the side of caution, since a programmer can augment the search path for the files if desired. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Re: Back-of-the-envelope cost of extra data :-)
by kennykb＠crd.ge.com May 9, 2005

May 9, 2005

olsona(a)lecserver.nci.nih.gov said: > One way to reduce data file growth is to store just 5 bytes of time_t > values rather than 8. Better still would be, in the 64-bit version, to keep all the timezones in a single file rather than using the file system as a database. You lose an incredible abount of space to internal fragmentation. On my Linux machine: % find /usr/share/zoneinfo -type f -print | xargs cat | wc -c 873941 % du -k -s /usr/share/zoneinfo 5136 /usr/share/zoneinfo So there's a little over 5 megabytes of zoneinfo files (much of it in the 'right' rules), but less than 900 kilobytes of actual data. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Re: Back-of-the-envelope cost of extra data :-)
by kennykb＠crd.ge.com May 4, 2005

May 4, 2005

kre(a)munnari.oz.au said: > If at some future point the code is going to switch from the tables, > to an algorithmic conversion, why bloat the tables by including so > much speculative future data? Exactly what I've been saying - except that for some reason my messages haven't been getting to the mailing list. I'm perfectly comfortable with today's tables that go out to Y2038 and resorting to a single rule for the fictitious timezone that exists thereafter. (We need to expand the table format so that as Y2038 approaches, we can extend the data past it, but that's by no means urgent.) Really, I find the whole argument ridiculous. Incidentally, for whatever it's worth, todays zoneinfo files occupy about 5.1 megabytes on my Linux box. The actual data are only about 450 kilobytes; the rest results from internal fragmentation. A gzip'ped tarball of the zoneinfo files compresses down to a bit over 250 kilobytes. (This include the 'right' files; Tcl's selected set compresses to 190 kilobytes, even though its information files are text files. Tcl doesn't need the 'right' files, ever, because its model of time has no leap seconds - it's similar to Markus Kuhn's UTS.) -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Back-of-the-envelope cost of extra data :-)
by Olson, Arthur David (NIH/NCI) May 4, 2005

May 4, 2005

This output... Script started on Wed 04 May 2005 10:15:00 AM EDT lecserver$ du -s tz*/tmp/*/zoneinfo 489 tz/tmp/etc/zoneinfo 1709 tzexp/tmp/etc/zoneinfo lecserver$ exit script done on Wed 04 May 2005 10:15:08 AM EDT ...indicates that "old-format" data eats up about half a megabyte of disk space total while "new-format" data eats up about 2 megabytes. (Some individual files grow by a factor of 9; others don't grow at all; the final result lies between these extremes.) At a dollar per gigabyte of disk space, the old stuff costs one twentieth of a cent per computer while the new stuff costs four twentieths of a cent per computer, for a difference of three twentieths of a cent. Making a wild estimate of one computer per person, there are about 6.5 billion computers in the world. In this case I'm happy if 90% are running Windows, since Microsoft doesn't ship time zone files. That leaves at most 650 million computers where the time zone files might show up. Maximum total cost: 650 million computers * three twentieths of a cent: $975,000 (ulp!) Frightening corollary: 1024 bytes of Microsoft code bloat costs the world economy $5850. --ado

3 2

Re: Proposed 64-bit changes
by kennykb＠crd.ge.com May 4, 2005

May 4, 2005

mark.davis(a)jtcsv.com said: > A. Extend by last year. > B. No Daylight > C. Others? I find both (A) and (B) acceptable. The politicians routinely diddle with the Daylight Saving Time rules. Even the year after the next is conjectural - what the rules will be in a century, or 400 years, is pure speculation. As long as something resembling the correct time of day is returned, the results should be entirely adequate. In short, Y2038 bugs in Daylight Saving Time processing are the least of our worries. As I said, in Tcl's analogue to zic (http://tip.tcl.tk/173) I put in an arbitrary cutoff (easily changed) of 2100. I suspect it ought to be shorter. (And I do get complaints about the footprint taken up with the zoneinfo files, owing to the places where they wind up ROMmed.) -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

RE: Proposed 64-bit changes
by Robbin Kawabata May 4, 2005

May 4, 2005

> From: "Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> > To: "'Robbin Kawabata'" <Robbin.Kawabata(a)eng.sun.com>, "Tz (tz(a)elsie.nci.nih.g ov)" <tz(a)elsie.nci.nih.gov> > Subject: RE: Proposed 64-bit changes > Date: Mon, 2 May 2005 09:46:29 -0400 > > > Is it feasible for zic to encode variable information in the data file for > > the last set of rules, that would be used for times past the last entry in > > the transition table? Then localtime() > > would use the variables algorithmically rather than using table-driven > > data, for dates past the last table entry. Perhaps set a minimum size for > > the table entries (ie, have table entries > > at least up to year xxxx.) > > This approach isn't as general as the extend-400-years approach. Take, for > example, the proposal a few years back to extend DST into November in the > Pacific Time Zone in presidential election years (as a way of minimizing > announced results from New York affecting voting in California). The > irregularities that would have resulted can't be handled by a POSIX-style > rule string; they can be handled by the extend-400-years approach. To address these types of timezones, zic could write a second set of variables. One set of variables would be used (for example) for nonpres years, and one set of variables would be used for uspres years. As a side note, our standards representative comments that POSIX TZ rules have been extended in recent years to be more flexible than they had been in the past, and would likely be extended again if uspres, even, odd, or other rules are actually put into practice. After more discussion here, we feel the extend-400-year approach would be acceptable. We would be OK with either the extend-400-year approach or the variable approach. Robbin

4 3

Re: Proposed 64-bit changes
by kennykb＠crd.ge.com May 3, 2005

May 3, 2005

To me, "extend 400 years" seems actually a trifle excessive, since Daylight Saving Time rules appear to have a mean lifespan of a decade or so. The meaning of a given time zone that far in the future is, to put it mildly, conjectural. In Tcl's 'zic' counterpart (http://tip.tcl.tk/173) I decided somewhat arbitrarily to go out 100 years as a compromise between Y2038 bugs and disc footprint. If we all settle on 400 years as the standard, I could of course change that, but I'm reluctant to spend the space on it. (Tcl has a way of getting ported to strange places like routers and X-ray machines.) As I said, it sounds a bit excessive, because civil time zones are not stable for anywhere near that length of time. Messing around with the clocks seems to be one favorite activity of governments that want to give the impression that they're doing something. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Postponed code pushes
by Olson, Arthur David (NIH/NCI) May 3, 2005

May 3, 2005

Given comments about increased data file size and about storing rules in the data files, I'm holding off on incorporating the proposed 64-bit changes in the ftp version of the time zone package. I welcome additional comments on these matters; in particular, is adding a "short-output" option to zic a way of addressing the concern, and is it a good idea (given that it will slow the spread of new-format data file)? I'm also holding off on handling TZ strings such as "<UTC+10>-10", with security in mind (as mentioned by other folks on the time zone mailing list). On the one hand, a string such as "<UTC+10>10\nX-Arbitrary-Mail-Header: Arbitrary-Value" could be used to forge a mail header. On the other hand, there are far easier ways forge mail headers. Is there anything that could be done by a carefully selected TZ value that can't be done more easily in other ways? --ado

2 1

TZ corrections
by Jesper Norgaard Welen May 2, 2005

May 2, 2005

For the Palmer station in Antarctica, the rule ArgAQ has been declared. But the rule ArgAQ is not used until 1965, while the rule is defined for year 1964. Therefore it would be more reasonable to redefine it the following way: -Rule ArgAQ 1964 1966 - Mar 1 0:00 0 - -Rule ArgAQ 1964 1966 - Oct 15 0:00 1:00 S +Rule ArgAQ 1965 1966 - Mar 1 0:00 0 - +Rule ArgAQ 1965 1966 - Oct 15 0:00 1:00 S Zone Antarctica/Palmer 0 - zzz 1965 -4:00 ArgAQ AR%sT 1969 Oct 5 In the Argentina timezones, it seems that apart from the initial LMT (which is of course different), the Catamarca timezone and the Chubut timezone are in fact identical, so I suggest: # # Catamarca (CT) Zone America/Argentina/Catamarca -4:23:08 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 -3:00 Arg AR%sT 1991 Mar 3 -4:00 - WART 1991 Oct 20 -3:00 Arg AR%sT 1999 Oct 3 -4:00 Arg AR%sT 2000 Mar 3 -3:00 - ART 2004 Jun 1 -4:00 - WART 2004 Jun 20 -3:00 - ART # # Chubut (CH) # The name "Comodoro Rivadavia" exceeds the 14-byte POSIX limit. -Zone America/Argentina/ComodRivadavia -4:30:00 - LMT 1894 Oct 31 - -4:16:48 - CMT 1920 May - -4:00 - ART 1930 Dec - -4:00 Arg AR%sT 1969 Oct 5 - -3:00 Arg AR%sT 1991 Mar 3 - -4:00 - WART 1991 Oct 20 - -3:00 Arg AR%sT 1999 Oct 3 - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART 2004 Jun 20 - -3:00 - ART +Link America/Argentina/Catamarca America/Argentina/ComodRivadavia In the 'asia' file, the EUAsia rule is defined from 1981 to max. In fact, it is not used for any timezones before 1996, so I suggest: -Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S +Rule EUAsia 1996 max - Mar lastSun 1:00u 1:00 S Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT 4:00 - AZT 1996 # Azerbaijan time 4:00 EUAsia AZ%sT 1997 The E-EurAsia rule is defined from 1979, but not used until 1992. I suggest: -Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 S -Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 - +Rule E-EurAsia 1992 max - Mar lastSun 0:00 1:00 S +Rule E-EurAsia 1992 1995 - Sep lastSun 0:00 0 - Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 - 3:00 RussiaAsia GE%sT 1992 # Georgia Time 3:00 E-EurAsia GE%sT 1994 Sep lastSun 4:00 E-EurAsia GE%sT 1996 Oct lastSun 4:00 1:00 GEST 1997 Mar lastSun 4:00 E-EurAsia GE%sT 2004 Jun 27 3:00 RussiaAsia GE%sT As far as I can see, the 1949-part of the PRC rule doesn't actually have any effect, so it could be deleted: -Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D As we see below, only in Shanghai it is inside a time range where it is activated, but as far as I can see, before and after the rule, GMT offset will be +8: Zone Asia/Harbin 8:26:44 - LMT 1928 # or Haerbin 8:30 - CHAT 1932 Mar # Changbai Time 8:00 - CST 1940 9:00 - CHAT 1966 May 8:30 - CHAT 1980 May 8:00 PRC C%sT # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT # Long-shu Time (probably due to Long and Shu being two names of that area) Zone Asia/Chongqing 7:06:20 - LMT 1928 # or Chungking 7:00 - LONT 1980 May # Long-shu Time 8:00 PRC C%sT # Xin-zang Time ("Xinjiang-Tibet Time") Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time 8:00 PRC C%sT # Kunlun Time Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May 8:00 PRC C%sT In my home country Denmark, it seems that there is a superfluous rule for 2.nd of April 1945, which I suggest to delete: Rule Denmark 1940 only - May 15 0:00 1:00 S -Rule Denmark 1945 only - Apr 2 2:00s 1:00 S Rule Denmark 1945 only - Aug 15 2:00s 0 - Unles my interpretation is wrong, both before and after the rule takes effect in April 2, 1945, the time in Denmark would be GMT+2 (e.g. GMT+1 +1), or does it mean that time is GMT+3? As a side-question, I haven't been able to check this with any Time Zone Converter (the web version has a cutoff date of 1970). Is there any way to check this by a program, and which? Concerning the original definition for Denmark: Zone Europe/Copenhagen 0:50:20 - LMT 1890 - 0:50:20 - CMT 1894 Apr # Copenhagen Mean Time + 0:50:20 - CMT 1894 Jan 1 0:00 # Copenhagen Mean Time 1:00 Denmark CE%sT 1942 Nov 2 2:00s I found some references in old on-line lawtexts in Denmark: The page http://www.hum.aau.dk/~poe/tid/tine/DanskTid.htm says that the law was in effect from 1. January 1894, not from April. The page http://www.retsinfo.dk/_GETDOCI_/ACCN/A18930008330-REGL confirms this, and states that the law was put forth 29.th. of March 1893 specifying that it would be in effect from 1.st. of January 1894. The EU treaty with effect from 1973: http://www.retsinfo.dk/_GETDOCI_/ACCN/A19722110030-REGL This provoked a new law from 1974 to make possible summer time changes in subsequenet decrees with the law http://www.retsinfo.dk/_GETDOCI_/ACCN/A19740022330-REGL It seems however that no decree was set forward until 1980. I have not found any decree, but in another related law, the effecting DST changes are stated explicitly: to be from 6.th. of April 1980 at 2.00 to 28.th. of September 1980 at 2.00. If this is true, this differs slightly from the EU rule in that DST runs to 2.00, not 3.00. We don't know when Denmark began using the EU rule correctly, but we have only confirmation of the 1980-time, so I presume it was correct in 1981: The law is about the management of the extra hour, concerning working hours reported and effect on obligatory-rest rules (which was suspended on that night): http://www.retsinfo.dk/_GETDOCI_/ACCN/C19801120554-REGL I suggest the following changes: Rule Denmark 1948 only - Aug 8 2:00s 0 - +Rule Denmark 1980 only - Apr Sun>=1 2:00 1:00 S +Rule Denmark 1980 only - Sep lastSun 2:00 0 - # Whitman also gives 1949 Apr 9 to 1949 Oct 1, and disagrees in minor ways # about many of the above dates; go with Shanks. # -# For 1894, Shanks says Jan, Whitman Apr; go with Whitman. +# For 1894, Shanks says Jan, Whitman Apr; go with Shanks. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Copenhagen 0:50:20 - LMT 1890 - 0:50:20 - CMT 1894 Apr # Copenhagen Mean Time + 0:50:20 - CMT 1894 Jan 1 0:00 # Copenhagen Mean Time 1:00 Denmark CE%sT 1942 Nov 2 2:00s 1:00 C-Eur CE%sT 1945 Apr 2 2:00 - 1:00 Denmark CE%sT 1980 + 1:00 Denmark CE%sT 1981 1:00 EU CE%sT In Norway, I accidentally tripped over some new information from the Metheorological Institute in Norway, citing information from The Theoretical Astrophysics Institute of the University in Oslo: http://met.no/met/met_lex/q_u/sommertid.html This in effect confirms the information from Shanks, although there is a discrepancy for 1940-1942. I suggest the following changes: # Norway # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Whitman gives 1916 May 21 - 1916 Oct 21; go with Shanks. Rule Norway 1916 only - May 22 1:00 1:00 S Rule Norway 1916 only - Sep 30 0:00 0 - # Whitman says DST observed 1935-08-11/1942-11-01, then 1943-03-29/10-04, -# 1944-04-03/10-02, and 1945-04-01/10-01; go with Shanks. +# 1944-04-03/10-02, and 1945-04-01/10-01; Shanks says C-Eur rules from +# August 10, 1940. Go with Oslo University, Institute for Astrophysics, +# see http://met.no/met/met_lex/q_u/sommertid.html. +Rule Norway 1940 only - Aug 11 2:00s 1:00 S +Rule Norway 1942 only - Nov 2 2:00s 0 - Rule Norway 1945 only - Apr 2 2:00s 1:00 S Rule Norway 1945 only - Oct 1 2:00s 0 - Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 - Rule Norway 1965 only - Apr 25 2:00s 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 - 1:00 Norway CE%sT 1940 Aug 10 23:00 + 1:00 Norway CE%sT 1943 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Norway CE%sT 1980 1:00 EU CE%sT Regards, Jesper Nørgaard Welen Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

6 7