- tz - lists.iana.org

strftime("%Z") invalidated by TZ change: is this a fair restriction?
by Jonathan Lennox June 12, 2001

June 12, 2001

This is an issue that occured to me in the process of converting tzcode to support my proposed thread-safe API. I think the following restriction is necessary to the POSIX 200x spec. If a 'struct tm' broken-down time structure is created by localtime() or localtime_r(), or modified by mktime(), and the value of the "TZ" environment variable is subsequently modified, the results of the %Z and %z strftime() and wcsftime() conversion specifiers are undefined, when strftime() or wcsftime() is called with such a broken-down time structure. If the broken-down time structure is subsequently modified by a successful call to mktime(), the results of these conversion specifiers are once again defined. If a 'struct tm' broken-down time structure is modified by gmtime(), it is implementation-defined whether the result of the %Z and %z strftime() and wcsftime() conversion specifiers shall refer to UTC or the current local time zone, when strftime() or wcsftime() is called with such a broken-down time structure. I think it's too late to get this restriction into the Austin Group revised POSIX spec, but some version of it probably ought to go into the tzcode man pages (along with documentation of what tzcode does for the second case, which is dependent on the value of TM_ZONE and TM_GMTOFF at compile-time). The motivating example for the first two paragraphs is the code attached below (test-tzchange.c). It produces the following output on FreeBSD 4.3 (which uses a slightly old version of tzcode, with some local changes that shouldn't affect this; it defines TM_ZONE and TM_GMTOFF): $ ./test-tzchange Fri 04 May 11:11:00 2001 EDT Fri 04 May 11:11:00 2001 PPT Fri 04 May 11:11:00 2001 PDT This occurs because lclptr->chars has a different value for the two time zones; since test_tm->tm_zone is a pointer into lclptr->chars, it ends up pointing somewhere bogus, and thus claiming that "Pacific Peace Time" was used in 2001. I don't think it's possible to fix this in tzcode without either breaking binary compatibility of 'struct tm', leaking memory on a TZ change, or breaking %Z for non-current time zones. The motivating example for the third paragraph is that System V (at least Solaris) and tzcode do different things, and I don't think either one is about to change. (System V always gets its %Z from tzname[i], I think.) The underlying motivation for all this is that I don't see any sensible way to set tm_zone, for struct tm's produced by reentrant timezone functions, that doesn't end up leading to free pointer dereferences following tz_free(). However, if the analogous operation for process-wide timezones is *already* undefined, it's clearly not nearly as much of a problem. What do people think about this? #include <stdio.h> #include <time.h> #include <stdlib.h> /* #define OLD_NAMES */ #ifdef OLD_NAMES /* Define this on Solaris */ #define FIRST_NAME "US/Eastern" #define SECOND_NAME "US/Pacific" #else /* Proper Olson tzdata names. */ #define FIRST_NAME "America/New_York" #define SECOND_NAME "America/Los_Angeles" #endif int main() { struct tm* test_tm; time_t then = 988989060; char buf[256]; /* Compatibility names are used, rather than new Olson names, so as to * test on Solaris. */ if (putenv("TZ=" FIRST_NAME) != 0) { fprintf(stderr, "putenv failed (1)\n"); exit(1); } if ((test_tm = localtime(&then)) == NULL) { fprintf(stderr, "localtime failed\n"); exit(1); } if (strftime(buf, sizeof(buf), "%a %d %h %H:%M:%S %Y %Z", test_tm) == 0) { fprintf(stderr, "strftime failed (1)\n"); exit(1); } printf("%s\n", buf); if (putenv("TZ=" SECOND_NAME) != 0) { fprintf(stderr, "putenv failed (2)\n"); exit(1); } tzset(); if (strftime(buf, sizeof(buf), "%a %d %h %H:%M:%S %Y %Z", test_tm) == 0) { fprintf(stderr, "strftime failed (2)\n"); exit(1); } printf("%s\n", buf); test_tm->tm_isdst = -1; if (mktime(test_tm) == -1) { fprintf(stderr, "mktime failed\n"); exit(1); } if (strftime(buf, sizeof(buf), "%a %d %h %H:%M:%S %Y %Z", test_tm) == 0) { fprintf(stderr, "strftime failed (3)\n"); exit(1); } printf("%s\n", buf); exit(0); } -- Jonathan Lennox lennox(a)cs.columbia.edu

2 1

Minimap of russian cities
by Jesper Nørgaard June 10, 2001

June 10, 2001

I thought you might like to have a mini-map of how the russian cities I mentioned, appears on the map of World Time Explorer: Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista 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 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://www20.Brinkster.com/timezone50/index.htm http://members.theglobe.com/timezone50/index.htm

1 0

Re: Proposal: API for thread-safe time zone functions
by Russ Allbery June 9, 2001

June 9, 2001

Garrett Wollman <wollman(a)khavrinen.lcs.mit.edu> writes: > (In the FreeBSD Project, and probably many other places, our coding > standard is very explicit: don't use typedefs for structures. This > deficiency in C is precisely the reason for making that requirement.) I'm completely with Garrett on this. Pointers to incomplete structs make *great* opaque datatypes in C; typedefs have considerably more problems and are really annoying to deal with. It's really a shame that FILE wasn't instead defined as a pointer to an incomplete struct, since the way it works right now, lots of headers that have no need whatsoever of all the crap in stdio.h have to include it solely because there's one function (which many callers may not even use) that takes a FILE * as an argument. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(no subject)
by Kim McGarghan June 8, 2001

June 8, 2001

unsubscribe

1 0

Change in DST for Argentina
by Syed Sajjath June 8, 2001

June 8, 2001

Hi, Is anyone aware of changes in Argentina to add Daylight Savings. One of my contacts sent the following information. From TZ database, Argentina is GMT -3 and no DST. >> With this, timezone for Argentina will be modified as follows: >> from 1st Sunday October until first Saturday March: GMT -3 >> from 1st Sunday Martch until first Saturday October: GMT -4 Thanks -Syed

2 1

Dave Wilson: Drowning in a Sea of Clocks
by Paul Eggert June 8, 2001

June 8, 2001

In yesterday's Los Angeles Times, Dave Wilson wrote a humorous piece "Drowning in a Sea of Clocks" complaining about the number of clocks he has to change every spring and fall. He goes on: Like all good paranoid fantasies, mine has a villain: the Japanese. Japanese electronics designers have been deliberately building clocks into everything in hopes of weakening our industrial might. Now, you might say, "Dave, that's crazy talk. The Japanese have a lot more of these gadgets than we do. They're gadget freaks, man. They'd be hurt by this as much as we are, or even more." Which shows how much you know, pal. The Japanese don't have daylight saving time. He finally resolves to disable all his clocks that serve no function. (His oven clock now blinks 00:00.) See: http://www.latimes.com/business/cutting/20010405/t000029080.html

2 1

Additional Greenland time zone
by Gwillim Law June 7, 2001

June 7, 2001

Does anyone out there speak Norwegian or Danish? The tz database lists only three time zones for Greenland, with standard time equal to UTC-1, UTC-3, and UTC-4. Some recent time zone maps (e.g. <http://www.hammondmap.com/timezone/maintz.html>) show a fourth time zone in northeast Greenland with UTC as its standard time. Doing some Internet research, I found a document, "Notices to Mariners", in Norwegian and English, at <http://www.statkart.no/efs/efshefter/2001/efs5-2001.pdf>. The following excerpt obviously has a good deal of useful information, but appears in Norwegian only. "220. (T). Grønland. Sommertid 2001. Sommertiden begjynner den 24. mars 2001. Grønland har 4 lokale tider, og i relasjon til UTC gjelder følgende tidslinje: Forsvarsområdetved Thule UTC-4 Grønlandsk normaltid UTC-3 Scoresby-sund UTC-1 Danmarks-havn UTC Danmark (Mellem-europæisk tid) UTC+1 Sommertid innføres som følger: 1. Grønlandsk normaltid: Den 24. mars 2001 kl. 2200 stilles uret frem til kl. 2300. 2. Scoresbysund: Den 25. mars 2001 kl. 0000 stilles uret frem til kl. 0100. 3. I forsvarsområdet ved Thule samt i Danmarkshavn innføres det ikke sommertid." What I make of this is: Greenland Summer time begins on 24 March 2001. Greenland has four local times, and the relation to UTC is according to the following time line: [the following five items are aligned horizontally] Thule and environs [?] UTC-4 Standard Greenland time UTC-3 Scoresbysund UTC-1 Danmarkshavn UTC Denmark (Central European Time) UTC+1 Summer time [...?] 1. Standard Greenland time: on 24 March 2001 at 22:00 change the clock to 23:00 [?] 2. Scoresbysund: on 25 March 2001 at 00:00 change the clock to 01:00 3. In the environs of Thule together with Danmarkshavn [...?]." Here's an excerpt from another page <http://www.gh.gl/kn/news/govern/ukiunalun.htm>, probably in Danish: "Vintertid fra på søndag den 31. oktober Uret stilles en time tilbage Natten mellem lørdag og søndag den 31. oktober 1999 slutter sommertiden. Der skiftes officielt lørdag den 30. oktober 1999 kl. 23:00. Det betyder, at vi kl. 23:00 stiller klokken en time tilbage til kl. 22:00. For Ittoqqortoormiit slutter sommertiden søndag den 31. oktober 1999 kl. 01:00, hvor klokken stilles een time tilbage til kl. 00:00. For Danmarkshavn og i forsvarsområdet i Pituffik er der ikke indført sommertid/vintertid." It looks as if this means that in most of Greenland, the clock turned back from 30 October 1999 23:00 to 22:00. In Ittoqqortoormiit (= Scoresbysund), it went from 31 October 1999 01:00 to 00:00. In Danmarkshavn and Pituffik (= Thule), something else happened, but I can't tell what. There are similar texts on <http://www.statkart.no/efs/efshefter/2000/efs5-2000.pdf>, <http://www.gh.gl/dk/nyheder/regering/2000/meddelt1610-2.htm>, and <http://www.epr.gl/government/dk_pressrel/160301_sommertid.html>. It looks as if they're all paraphrased from official Greenland press releases. Can anyone translate the rest, or fill in any more details? Gwillim Law

2 1

RE: [akr@m17n.org: bin/27630: mktime problem.]
by Olson, Arthur David (NCI) June 6, 2001

June 6, 2001

Garrett's analysis of the cause of the Africa/Monrovia problem is accurate (see the end of this message). The conservative approach to fixing the problem would be as shown just below. The more radical approach would be to ditch the saved_seconds hackery completely; it predates the conditional normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, SECSPERMIN) call that now appears in the code, which should do what the saved_seconds hackery was designed to do. --ado *** 7.73/localtime.c Tue Jun 5 14:04:57 2001 --- 7.74/localtime.c Tue Jun 5 14:04:57 2001 *************** *** 1383,1389 **** } if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; ! if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. --- 1383,1391 ---- } if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; ! if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) ! saved_seconds = 0; ! else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. -----Original Message----- From: Garrett Wollman [mailto:wollman@khavrinen.lcs.mit.edu] Sent: Friday, May 25, 2001 2:01 PM To: tz(a)elsie.nci.nih.gov Subject: [akr(a)m17n.org: bin/27630: mktime problem.] A FreeBSD user submitted the following bug report. I'm curious as to whether the current tzcode still has this problem. My analysis follows at the end. -GAWollman ... For example, TZ=Africa/Monrovia, 1972/05/01 00:44:30 cannot be converted to time_t. Since this example is taken from `zdump -v Africa/Monrovia' and it is after Epoch, there is no reason to fail. ... This problem appears to result from the `saved_seconds' hackery in time2(): saved_seconds = yourtm.tm_sec; yourtm.tm_sec = 0; time2() then goes on to attempt to find (in this example) 1972-05-01T00:44:00, which does not exist in this time zone, and returns failure.

1 0

tzcode2001c.tar.gz and tzdata2001.tar.gz
by Olson, Arthur David (NCI) June 6, 2001

June 6, 2001

The files ftp://elsie.nci.nih.gov/pub/tzcode2001c.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2001c.tar.gz are now available. These incorporate the changes circulated last week on the time zone mailing list by Paul Eggert and Andrew Brown. --ado

1 0

[The Times 2001-06-02] Timezone cheats using Net for exams
by Joseph S. Myers June 3, 2001

June 3, 2001

From Saturday's Times: SATURDAY JUNE 02 2001 Timezone cheats using Net for exams BY GLEN OWEN, EDUCATION CORRESPONDENT, AND LAURA PEEK IN WASHINGTON A GLOBAL network of timezone cheats has been established on the Internet to pass examination secrets between candidates. Overseas students, who start the same papers at staggered intervals because of international time differences, are corresponding with candidates who have already finished their exams. The English examination boards alerted to the scam by The Times, have promised to review procedures, and warn that any candidate found cheating will be disqualified. One board admitted that the growth of Internet use and mobile text messaging presented a significant twist to an old problem. Schools in Brazil, Bermuda, the USA and Canada, also contacted by The Times yesterday, said they would be reviewing examination procedures to prevent time-zone cheating. [ ... - for full article see Times website: ] http://www.thetimes.co.uk/article/0,,2-2001190449,00.html http://www.thetimes.co.uk/article/0,,59-2001190216,00.html -- Joseph S. Myers jsm28(a)cam.ac.uk

1 0