- tz - lists.iana.org

RE: Solaris mktime with multiple timezones
by Olson, Arthur David (NCI) Nov. 23, 1998

Nov. 23, 1998

I compiled the small program (bugtest.c) mentioned in the letter below using the latest elsie.nci.nih.gov source; the program ran okay. As Scott mentions, folks on the mailing list probably do need to be aware of the bug. --ado From: Scott Harrington [SMTP:seh4@ix.netcom.com] Sent: Friday, November 06, 1998 1:16 PM Subject: BUG: Solaris mktime with multiple timezones I have posted the attached message to comp.unix.solaris, so replies should probably be posted there. I wanted to notify this mailing list since the bug affects those who use multiple time zones in their programs... I have uncovered a bug in the mktime() routine found in libc.so.1 and libc.a on my SunOS 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-2 machine: -rw-r--r-- 1 bin bin 1155756 Jun 23 1997 /usr/lib/libc.a -rwxr-xr-x 1 bin bin 664760 Jun 23 1997 /usr/lib/libc.so.1 I have attached a small program which should determine if your system has the bug or not.

1 0

FW: symlinks in zic
by Olson, Arthur David (NCI) Nov. 17, 1998

Nov. 17, 1998

-----Original Message----- From: Mani Varadarajan [SMTP:mani@be.com] Sent: Monday, November 16, 1998 9:04 PM To: eggert(a)twinsun.com; tz(a)elsie.nci.nih.gov Subject: symlinks in zic Dear Time Zone experts, I incorporated your timezone database into the BeOS last year. The BeOS file system does not support hard links, so I had to implement symbolic link support myself. Judging from the latest version of tzcode, which I just stumbled upon today, I notice that you have done the same. I suggest a few changes to your implementation, detailed in the attached diff. The problem with how it is right now is that if zic is invoked as follows: zic -d foodir <rules files> where foodir is a relative and not an absolute path, the symbolic links in the timezone database point to bogus places. (We use relative paths in our build environment at Be during our daily builds of the BeOS.) My proposed changes fix this problem. We have used my modified version of zic for over a year now in production without any problems. Please let me know what you think of the changes. I am not on this list so please keep me on the CC list. Thanks, Mani *** zic.c.old Mon Nov 16 17:48:18 1998 --- zic.c Mon Nov 16 16:47:55 1998 *************** *** 605,616 **** if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! result = symlink(fromname, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); } #endif if (result != 0) { --- 605,624 ---- if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); + result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! char *s = (char *) tofile; ! register char * symlinkcontents = NULL; ! while ((s = strchr(s+1, '/')) != NULL) ! symlinkcontents = ecatalloc(symlinkcontents, "../"); ! symlinkcontents = ecatalloc(symlinkcontents, fromfile); ! ! result = symlink(symlinkcontents, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); + ifree(symlinkcontents); } #endif if (result != 0) {

1 0

symlinks in zic
by Mani Varadarajan Nov. 17, 1998

Nov. 17, 1998

Dear Time Zone experts, I incorporated your timezone database into the BeOS last year. The BeOS file system does not support hard links, so I had to implement symbolic link support myself. Judging from the latest version of tzcode, which I just stumbled upon today, I notice that you have done the same. I suggest a few changes to your implementation, detailed in the attached diff. The problem with how it is right now is that if zic is invoked as follows: zic -d foodir <rules files> where foodir is a relative and not an absolute path, the symbolic links in the timezone database point to bogus places. (We use relative paths in our build environment at Be during our daily builds of the BeOS.) My proposed changes fix this problem. We have used my modified version of zic for over a year now in production without any problems. Please let me know what you think of the changes. I am not on this list so please keep me on the CC list. Thanks, Mani *** zic.c.old Mon Nov 16 17:48:18 1998 --- zic.c Mon Nov 16 16:47:55 1998 *************** *** 605,616 **** if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! result = symlink(fromname, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); } #endif if (result != 0) { --- 605,624 ---- if (mkdirs(toname) != 0) (void) exit(EXIT_FAILURE); + result = link(fromname, toname); #if (HAVE_SYMLINK - 0) if (result != 0) { ! char *s = (char *) tofile; ! register char * symlinkcontents = NULL; ! while ((s = strchr(s+1, '/')) != NULL) ! symlinkcontents = ecatalloc(symlinkcontents, "../"); ! symlinkcontents = ecatalloc(symlinkcontents, fromfile); ! ! result = symlink(symlinkcontents, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); + ifree(symlinkcontents); } #endif if (result != 0) {

1 0

FW: Asia/Ishigaki?
by Olson, Arthur David (NCI) Nov. 16, 1998

Nov. 16, 1998

-----Original Message----- From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] Sent: Monday, November 09, 1998 6:50 AM To: tz(a)elsie.nci.nih.gov Subject: Re: Asia/Ishigaki? I also examined other data concerning Japan in tzdata1998i. The patch at the bottom of this mail fixes the following points. - Only one timezone JST is used everywhere in Japan. - In tzdata1998i, the location of 'Tokyo' (+3542+13946) seems to be around the University of Tokyo. However, 'Tokyo' usually stands for the former location of Tokyo Astronomical Observatory: E 139 44' 40".90 (9h 18m 58s.727), N 35 39' 16".0. This data is from 'Rika Nenpyou (Chronological Scientific Tables) 1996' edited by National Astronomical Observatory of Japan. - JST (Japan Standard Time) has been used since Jan. 1, 1888 0:00AM (JST). The law is enacted on July 7, 1886. I couldn't understand the comment 'There is no information for Marcus.' Does anyone know what 'Marcus' is? -- hideyuki diff -u tzdata1998i/asia tzdata/asia --- tzdata1998i/asia Thu Sep 24 23:46:09 1998 +++ tzdata/asia Mon Nov 9 20:12:24 1998 @@ -610,12 +610,9 @@ # We go with Shanks and omit daylight saving in those years for Asia/Tokyo. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Tokyo 9:19:04 - LMT 1896 +Zone Asia/Tokyo 9:18:59 - LMT 1887 9:00 - JST -Zone Asia/Ishigaki 8:16:36 - LMT 1896 - 8:00 - CST # There is no information for Marcus. -# Other Japanese possessions are probably like Asia/Tokyo. # Jordan # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S diff -u tzdata1998i/zone.tab tzdata/zone.tab --- tzdata1998i/zone.tab Thu Sep 24 23:46:11 1998 +++ tzdata/zone.tab Mon Nov 9 19:25:10 1998 @@ -188,8 +188,7 @@ IT +4154+01229 Europe/Rome JM +1800-07648 America/Jamaica JO +3157+03556 Asia/Amman -JP +3542+13946 Asia/Tokyo most locations -JP +2420+12409 Asia/Ishigaki south Ryukyu Islands +JP +3539+13944 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KH +1133+10455 Asia/Phnom_Penh

3 3

FW: Asia/Ishigaki?
by gwil＠mindspring.com Nov. 10, 1998

Nov. 10, 1998

>From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] > [...] >I couldn't understand the comment 'There is no information for Marcus.' >Does anyone know what 'Marcus' is? Marcus Island is the name used by Americans for Minami-Tori-shima. It's located at about 24 deg. 18 min. N., 153 deg. 58 min. E., which I think makes it the easternmost, as well as one of the southernmost, of the Japanese islands. It was administered by the U.S. military from the end of World War II to 1968. This background should help to explain why it's referred to by its American name, and why it might be expected to lie in a different time zone. -- Gwillim Law

1 0

FW: Asia/Ishigaki?
by Olson, Arthur David (NCI) Nov. 9, 1998

Nov. 9, 1998

-----Original Message----- From: Hideyuki Suzuki [SMTP:hideyuki@sat.t.u-tokyo.ac.jp] Sent: Saturday, November 07, 1998 11:54 AM To: tz(a)elsie.nci.nih.gov Subject: Asia/Ishigaki? In tzdata1998i.tar.gz, I found that two timezones are defined for Japan. This is somewhat strange to me, because only JST (+0900) is used everywhere in Japan including Ishigaki island. I want to suggest that Asia/Ishigaki (CST, +0800) zone should be removed. However, you may wonder why it was added to the database, and in tzarchive I found the following comment: Date: Tue, 3 Sep 1996 17:14:22 -0700 From: Paul Eggert <eggert(a)twinsun.com> Subject: proposed patch for selecting TZ, MET->CST, Sri Lanka, Antarctica,... > Asia/Ishigaki - uncomment it, since it seems to be right I don't know whether the zone was added at this time, but I suspect that it was added because of an ambiguous reason. So, I believe that it should be removed. I'm not on the tz list, so please leave my address in Cc: line when you reply. Thanks. -- hideyuki

1 0

Asia/Ishigaki?
by Hideyuki Suzuki Nov. 9, 1998

Nov. 9, 1998

In tzdata1998i.tar.gz, I found that two timezones are defined for Japan. This is somewhat strange to me, because only JST (+0900) is used everywhere in Japan including Ishigaki island. I want to suggest that Asia/Ishigaki (CST, +0800) zone should be removed. However, you may wonder why it was added to the database, and in tzarchive I found the following comment: Date: Tue, 3 Sep 1996 17:14:22 -0700 From: Paul Eggert <eggert(a)twinsun.com> Subject: proposed patch for selecting TZ, MET->CST, Sri Lanka, Antarctica,... > Asia/Ishigaki - uncomment it, since it seems to be right I don't know whether the zone was added at this time, but I suspect that it was added because of an ambiguous reason. So, I believe that it should be removed. I'm not on the tz list, so please leave my address in Cc: line when you reply. Thanks. -- hideyuki

1 1

BUG: Solaris mktime with multiple timezones
by Scott Harrington Nov. 6, 1998

Nov. 6, 1998

I have posted the attached message to comp.unix.solaris, so replies should probably be posted there. I wanted to notify this mailing list since the bug affects those who use multiple time zones in their programs. -------- Original Message -------- Subject: BUG: Solaris mktime with multiple timezones Date: Fri, 06 Nov 1998 18:09:17 +0000 From: Scott Harrington <seh4(a)ix.netcom.com> Newsgroups: comp.unix.solaris I have uncovered a bug in the mktime() routine found in libc.so.1 and libc.a on my SunOS 5.5.1 Generic_103640-12 sun4u sparc SUNW,Ultra-2 machine: -rw-r--r-- 1 bin bin 1155756 Jun 23 1997 /usr/lib/libc.a -rwxr-xr-x 1 bin bin 664760 Jun 23 1997 /usr/lib/libc.so.1 The error is that mktime() returns WRONG values when you're switching between multiple time zones in a single program. I have attached a small program which should determine if your system has the bug or not. I make a mktime call in GB timezone, and then in GMT timezone. The second lookup returns incorrect values. If you have the bug, your output will be: TZ=GB 892162800 0 0 0 10 3 98 5 99 1 should be TZ=GB 892162800 0 0 0 10 3 98 5 99 1 TZ=GMT 892162800 0 0 23 9 3 98 4 98 0 should be TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 On systems which implement mktime correctly, the output will be: TZ=GB 892162800 0 0 0 10 3 98 5 99 1 should be TZ=GB 892162800 0 0 0 10 3 98 5 99 1 TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 should be TZ=GMT 892166400 0 0 0 10 3 98 5 99 0 I am curious to find out on which systems this bug exists. (2.6? /opt/SUNWspro/lib/libc.so.1?) The public Sunsolve patch list apropos 'libc' only led me to patch 103612-46 (I already had 103612-30) and applying this patch did not fix the problem. I have a crude LD_PRELOAD workaround (using the implementation of mktime from GNU glibc-2.0.7) for existing executables, if anyone is interested let me know and I will mail it or post it to this newsgroup. #include <time.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { time_t t; { struct tm tmBuf = {0, 0, 0, 10, 3, 98, 0, 0, -1}; putenv("TZ=GB"); t = mktime(&tmBuf); printf("TZ=GB %ld %d %d %d %d %d %d %d %d %d", t, tmBuf.tm_sec, tmBuf.tm_min, tmBuf.tm_hour, tmBuf.tm_mday, tmBuf.tm_mon, tmBuf.tm_year, tmBuf.tm_wday, tmBuf.tm_yday, tmBuf.tm_isdst); printf(" should be\n"); printf("TZ=GB 892162800 0 0 0 10 3 98 5 99 1\n"); } printf("\n"); { struct tm tmBuf = {0, 0, 0, 10, 3, 98, 0, 0, -1}; putenv("TZ=GMT"); t = mktime(&tmBuf); printf("TZ=GMT %ld %d %d %d %d %d %d %d %d %d", t, tmBuf.tm_sec, tmBuf.tm_min, tmBuf.tm_hour, tmBuf.tm_mday, tmBuf.tm_mon, tmBuf.tm_year, tmBuf.tm_wday, tmBuf.tm_yday, tmBuf.tm_isdst); printf(" should be\n"); printf("TZ=GMT 892166400 0 0 0 10 3 98 5 99 0\n"); } exit(0); }

1 0

Re: new time conversion interface
by Nathan Myers Nov. 5, 1998

Nov. 5, 1998

Paul Hill wrote: > Nathan Myers wrote: > > > We're dealing with _humans_, here. It's a reasonable goal to try to > > increase the reliability of time entries by noting likely errors. > > ... > > A note that the time changed recently is *extremely* helpful when > > getting confirmation of a time entry, but most programmers are not > > equipped or inclined to root about in a transition database, > > Why would a programmer want to? To minimize mistakes. Any relevant information the system has that the user doesn't is a lost opportunity. People are not (uniformly) stupid, and can respond usefully to a notification that an entered time is dubious. Likewise, a logged timestamp annotated with reasons to doubt it may be more useful than a bare timestamp. The conversion function has discovered the information, the calling program is equipped to decide if it's useful. > The programmer asked to please > convert the fields into a timestamp given the TZ provided. I don't > see how going to look for other transition rules has anything to > do with it. There is still a list of possible interpretations > given just one possible fully accurate TZ definition. Current conversion functions don't report a list of possible interpretations, they report just one. That's what I'd like to fix in this interface. > Going looking > in a transition DB only provides more entries for the list returned > (An additional entry might capture a possible alternate based on > the possibility that the programmer really did not pass the library > the right TZ, because the library code can see that the given rules > did not apply on the date provided in the time struct.) The point is that the conversion function has just looked up all the relevant entries. It can discard any additional information it has gathered, or report it. The caller is equipped to choose which of the additional information is useful, but only if it's reported. > > I agree that the two examples are too similar. Originally I had > > #0 as the canonical "certain" time, and then realized that (as > > you noted) that condition is rare. At some point the likelihood > > of an error due to a transition becomes smaller than that of a > > simple typo, which can only be determined empirically. > > So how are you going to put that fuzzy set in the library code so > that sometimes you can return a "doubtful subsitution" and sometimes > you can return a "possible unofficial time"? Maybe instead of a "doubtful/possible" flag it just reports how long before the reported time the last transition occurred, and what the conversion would be if that one was missed. > > > Speaking of ambiguity, could you explain what your are really trying > > > to capture in #1 and #2, because your descriptions are of the same > > > circumstance. > > > > Er, that's a typo. ... > > > > The intended entry for #2 was 03:30. This is a valid "official" > > time, unlike 02:30. However, it is very likely to be wrong. > > But that makes the #2 entry jibberish, if I rewrite it as [gibberish] > Maybe it should be: > 2. Spring ambiguity, enter 03:30, but that is so close to the > change time it is suspicious. > > It would seem you could do the discussion of favor and repost a > complete list of possible combinations and what kind of rules you > are going to use to put your tags on all of the different > interpretations. That might not be the best description of the goal. The goal is a way for the conversion function to report the circumstances of the conversion in a form that is easily interpreted for different purposes. In my posting I was too specific about what are still unresolved design issues. > > Cases that are identical as far as the program is concerned > > (time is an hour off because of a clock not reset) are quite > > different in how the user experiences them. > > "identical as far as the program is concerned", but you are trying > to return two different values from the "alternative" time. > ... > One has to ask: since you have 16 possible return flag combinations, > could you please explain why only 5 of them are covered in your > list (and I see only 2), and what is right or wrong about the other > 11, i.e. "doubtful ... unofficial" etc. If you only have 5, just > have one enum that lists them and not imply states that don't exist. It may be that one enum with five values, or with four values and a field for when the last time change happened, would be appropriate. Again, you have identified a danger of being too specific. What I posted was an (unfortunately confusing) example meant to lend some concreteness to the discussion. Can we agree that it's useful for the conversion function to report (also) the circumstances of the conversion? Then we can proceed to explore how to report those circumstances. Nathan Myers ncm(a)cantrip.org

1 0

new time conversion interface
by ncm＠cantrip.org Nov. 5, 1998

Nov. 5, 1998

Apologies for following up my own posting, but I don't want to lose the thread here. I have edited the quoted text below for clarity. > > Nathan Myers wrote: > > > The problem with the mktime model is that conversions between civil > > > time and timestamps can result in 2, 1, or <1 valid conversions ... > > ... it's a rare wall clock, legal document, train schedule or > airline ticket that indicates UTC offset, and when it does it's > likely to be wrong, especially during the "interesting" times. > ... > The problem that normally arises is that someone enters a date/time > and I want a numeric real-time value. I distinguish the following > troublesome cases: > > 1. It's in spring and they enter 02:30, and that time doesn't exist, > but there's a good guess (e.g. equiv. to 03:30) for what > they probably meant. (There's a corresponding case for leap > seconds.) > 2. In spring they enter 03:30, which might be correct, but they might > well have meant 04:30 because they failed to reset their clock. > 3. In autumn, they enter 01:30; did they mean the first time it > happened that day or the second? Either is equally valid. > 4. (Also in autumn) If they enter 02:30, did they mean officially > 02:30, or did they mean the second 01:30? I believe that conversions should yield a struct containing a reference timestamp, followed by up to four offsets tagged with official wall-clock offset, interpretation, and confidence values. For example, in the cases above, and ignoring leap seconds for the moment, we would get 0. Unambiguous time, e.g. 04:30 morning of a time change t0=123456789 offset 0: 0 sec; wall-clock offset: -3600 sec; interpretation: unambiguous; confidence: certain offset 0: -3600 sec; wall-clock offset: -3600 sec. interpretation: suggested substitute; confidence: doubtful 1. Spring ambiguity, enter 02:30 when it doesn't exist because civil time proceeded 01:59:59 -> 03:00:00. (Or 02:00:00 to 03:00:01? I don't know.) t0=123456789 offset 0: 0 sec; wall-clock offset: -3600 sec. interpretation: suggested substitute; confidence: doubtful 2. Spring ambiguity, enter 02:30 when it doesn't exist because civil time proceeded 01:59:59 -> 03:00:00 (or whatever). t0=123456789 offset 0: 0 sec; wall-clock offset: 0 sec. interpretation: official choice; confidence: Nominally unambiguous offset 1: -3600 sec; wall-clock offset: 0 sec. interpretation: suggested substitute; confidence: doubtful 3. Autumn ambiguity, enter 01:30 on morning when civil time proceeds from 01:59:59 to 01:00; is it the first or second 01:30 event? t0=123456789 offset 0: 0 sec; wall-clock offset: 3600 sec. interpretation: ambiguous choice; confidence: equal alternative offset 1: 3600 sec; wall-clock offset: 0 sec. interpretation: ambiguous choice; confidence: equal alternative 4. Autumn, enter 02:30, same morning as above; did they mean the official 02:30, or did they mean the second 01:30 because they failed to reset their clock? t0=123456789 offset 0: 0 sec; wall-clock offset: 0 sec. interpretation: official choice; confidence: Nominally unambiguous offset 1: 3600 sec; wall-clock offset: 0 sec. interpretation: unofficial choice; confidence: Possible alternative For each case above one might have up to two more entries corresponding to leap-second ambiguities. The detailed semantics of all the possible "interpretation" and "confidence" tags must be nailed down. This might end up looking sort of like the following C struct layout, using deliberately unsatisfactory names for exposition: typedef ... time_stamp; /* something more-or-less numeric */ typedef enum { official, unofficial, ambiguous, suggested } time_meaning; typedef enum { nominal, alternative, possible, doubtful } time_confidence; struct time_interpretation { int offset; /* limited to +/- 3601 */ long wall_offset; /* limited to +/- 43200 */ time_meaning meaning; time_confidence confidence; }; struct time_from_civil { time_stamp reference_time; int interpretation_count; /* range 0-4 */ time_interpretation interpretation[4]; }; (I've neglected leap-second ambiguity interpretations because they would reduce the clarity of the exposition.) The conversion function might look like: int time_convert(const struct tm *, const time_zone *, time_from_civil *); I think an interface like this would encapsulate knowledge about time conversion issues, exposing a high-level view of the possible real-time values implied by wall-clock time records. I think it would lead to better, more robust interfaces for conversions, and reduce programmer errors. Comments? Nathan Myers ncm(a)cantrip.org

5 5

news from Estonia
by peter＠aldie.co.uk Nov. 4, 1998

Nov. 4, 1998

My relative in Estonia reports a rather confused picture. The law is clear enough: this year they changed to the EU rule time of 01:00 UTC from their previous midnight UTC. This is a change from 04:00 -> 03:00 local time. The newspapers didn't catch up though. They were still saying it was a change from 03:00 -> 02:00 local time. They can perhaps be forgiven for this as the new law was only dated 22 September. This spring in the UK the Times (a supposed `newspaper of record') printed a picture of a clock showing it going from 02:00 to 03:00. We haven't done that since 1980. The Estonian law can be found at: http://trip.rk.ee/cgi-bin/thw?${BASE}=akt&${OOHTML}=rtd&TA=1998&TO=1&AN=1390 Knowing my poor grasp of Estonian he offers the following free translation: According to the association agreement between the EU and the Republic of Estonia ratified by the Estonian law (RT II 1995, 22--27, 120) and in accordance with the 8th directive of EU 22. July 1997, 97/44/EU (EUT L 206, 1.08.1997, pp 62--63) the Government of Estonia decides to change to Summer Time as follows 1) start 3.00 by the zone time (1.00 GMT) on last sunday of March changing to 4.00; 2) end 4.00 by the zone time (1.00 GMT) on last sunday of October changing to 3.00) I also asked him whether they use any standard abbreviation for their standard and summer times. He says no, they use "suveaeg" (summer time) and "talveaeg" (winter time). He says there is still some discussion about whether they should continue fiddling with the clocks but didn't provide any specifics. Most Estonian newspapers have web pages linked from http://www.ee/www/Media/Journalism/Newspapers/welcome.html. The papers' pages are nearly all in Estonian only so I can't offer any more clues. Finally, this just confirms the existing data. No change is needed to the europe file. Peter Ilieve peter(a)aldie.co.uk

1 0

Re: new time conversion interface
by Ian Tragen Nov. 3, 1998

Nov. 3, 1998

> long wall_offset; /* limited to +/- 43200 */ > Re. the above - I may have missed something here but if you restrict the offset to +/-12 hours, you would run into difficulties with New Zealand DST which is UTC+13h. Ian Tragen -- World Clock Page:- http://www.page-1.com/time

1 0

Time Zone Converter
by Carroll, Nancy Oct. 30, 1998

Oct. 30, 1998

To Whom it May Concern, I am writing on behalf of Manitoba Trade with respect to your database of information used to operate a time zone converter. I am working on reconstruction of our website and in particular the method of constructing a time zone converter. Do you have any sort of licensing arrangement with respect to the use of your database? Do you allow your database to be used by outside sources? Could you please forward details of the nature of your operations and whether there is any way that we might be able to draw on your database of information for our time zone utility? Thank you very much for considering my inquiry. Sincerely, Nancy Carroll Manitoba Trade

1 0

timezone database
by Roy Valdehueza Oct. 27, 1998

Oct. 27, 1998

Dear TZ, i'm glad you guys are around. If you don't mind though i'd like to ask which file on your ftp site am i going to download if i need a timezone database? And what database format is this? How is it used (or at least you can give me which file will give me the mechanics or algorithm to use this database)? Thanx a lot and advance merry Christmas! Gratefully yours, roy valdehueza

1 0

new C time interface
by Nathan Myers Oct. 24, 1998

Oct. 24, 1998

[apologies if this has been seen before.] Part of the problem with struct tm/time_t is that it works ok for inode times but not for other equally-important uses. The problem with the mktime model is that conversions between civil time and timestamps can result in 2, 1, or <1 valid conversions, and neither the user (before the conversion) nor the library is equipped to favor one result over another, or deal properly with nonexistent times. mktime offers no interface for the algorithm to report what it finds, so it must falsify its results. I hope that any interface offered to improve on mktime will expose the information needed to write reliable code. If it is also "nice" for the common ranges where there actually is a one-to-one mapping, that's a bonus, but correctness should come first. Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

2 2

Re: new C time interface
by INFOMAN Inc. Oct. 23, 1998

Oct. 23, 1998

I tend to agree with Nathan's remarks on for new C time interface. The issue, i.e. need for, correctness in conversions and linkages between (local) civil times and timestamps is one that is also raised in the context of e-commerce and e-business and needs to be resolved. Jake Knoppers <mpereira(a)istar.ca>

1 0

Re: Proposal for new ISO C 9x time API
by Markus Kuhn Oct. 16, 1998

Oct. 16, 1998

Dear Timezone Gurus, I have now revised my proposal for a new <time.h> for C, which you can find on http://www.cl.cam.ac.uk/~mgk25/c-time/ When you have some time, please let me know what you think about it. Ideally we might manage to make this the basis for a proposal for ISO C9X. In case it is already too late for that, we might at least consider implementing it in the Olsen library and publish it independently (say via IETF as an RFC, or via the POSIX project). I have also added to the end of this page a pretty comprehensive list of links to online resources relevant to the topic, and a few more will come as soon as I have access to our scanner again. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

9 50

Re: Proleptic Gregorian and "Proleptik Julian xtime"
by INFOMAN Inc. Oct. 16, 1998

Oct. 16, 1998

The attached file "prolep.doc" is the extract from the entry in the Oxford English Dictionary (Second Edition) on Compact Disc. It may interest you all to know that Oxford records "proleptik" in use in Medieval times as meaning "predictive, prognostic" or "of the nature of a pre-assumption; pre-conceived; apriori; axiomatic"...etc. Nathan Myers is right when he states "proleptic" refers to the future not the past. The question is how far into the future to predict as can be noted in the following quotation in Oxford of pre-POSIX xtime calendar standardization efforts to determine the date at which God created the earth. Usher (1658) "Having placed therefore our heads of this Period in the Kalends of January, in that proleptik year, the first of our Christian vulgar account must be reckoned the 4717 of the Julian Period". This having been noted it is interesting that as we approach the 2nd millenium , we again have a "proleptic" debate. Jake Knoppers

1 0

Re: Proleptic Gregorian (was Re: Functions add/diff/cmp for xtime)
by Rich Wales Oct. 15, 1998

Oct. 15, 1998

Antoine Leca wrote: . . . TIME_TAI *or* TIME_UTC (as defined by Markus, with the added point that the calendar should be the proleptic Gregorian). Markus Kuhn replied: Question: What precisely does "proleptic" mean and where is it defined? . . . (I suspect it means "extended before the time it was defined", but would like to get a confirmation and reference.) Short answer: My understanding agrees with Markus's suspicion. Longer answer: I looked up the word in two respected American English dictionaries: the Webster's Ninth New Collegiate Dictionary (1985), and the American Heritage Dictionary (New College Edition, 1976). Webster's New Collegiate defines "prolepsis" (a noun) as "the represen- tation or assumption of a future act or development as if presently existing or accomplished", or "the application of an adjective to a noun in anticipation of the result of the action of the verb". "Proleptic" is listed as the corresponding adjective. The American Heritage defines "prolepsis" as "the anticipation and answering of an objection or argument before one's opponent has put it forward", or "the use of a descriptive word in anticipation of the act or circumstances that would make it applicable". It lists both "pro- leptic" and "proleptical" as adjective forms. Both dictionaries say the word is derived from Greek "prolambanein" (to take beforehand) < "pro-" (before) + "lambanein" (to take). Webster's New Collegiate says the first recorded use of the word in English was in 1578. So, the "proleptic Gregorian" calendar would be the result of extending the Gregorian calendar back into the past, before it came into use in a given location, or even before it was invented. My sense (as an educated native speaker of American English) is that "proleptic" and "prolepsis" are not commonly known or used by the aver- age English-speaking person. English is, of course, replete with such words, known primarily by authors, orators, and Scrabble players. Rich Wales richw(a)webcom.com http://www.webcom.com/richw/

4 3

synthesis ?
by Antoine Leca Oct. 14, 1998

Oct. 14, 1998

I believe we should try to advance beyond the points of disagreement exposed by some of us. I think the main point of disagreement is about the format of the basic type to be used for holding time. On one side, Clive Feather proposed an improvement over struct tm. OTOH, all others proposed improvements over time_t. If we followed this later way, I think we can classify all the possible implementations in the following order: 1st, those implementations that know both UTC and TAI "perfectly". I think this is the kind of implementations David has in mind. It is certainly the current case of tz-based up-to-date machines. It will also be the general case of the up-to-date boxes with Internet connection in a near future, IF our plan passes in C9X! 2nd, those implementations where the clock is UTC based and that have some knowledge about leap seconds, but where the famous table is not known to be correct. As Markus highlighted, and fears, this case is in my mind common, and should not be impaired too much; but it is only 2nd class. 3rd, those implementations that only know about UT, without any precision, and that don't know about leap seconds; in fact, it is like many informed people, or like Posix. 4th, worse, those implementations that even do not know about time zones, and that only know "some form of local time". Like Ms-Dos. 5th, if it even exists, those that cannot figure what time is it. I doubt it really exists, but traditionnaly C handles them. My idea is that the API to be proposed should work OK and smoothly with all classes, with priority given to the highest class(es) where there are choices to make. The main point is that everything (except the last class!) ends up as counts of seconds, and sometimes subseconds; but having to manage 2 functions for each functionnality seems too much for me; therefore I prefer something along the lines of struct taia or struct xtime. Not specifying what real kind of time counter is used is fairly frequent in the C standard: it is said to be unspecified. Sometimes, Markus's xtime_conv would then permit to convert this unspecified format to some other its application is aimed at (we have now numerous examples of applications where either TAI, either UTC or decomposed Gregorian are better fitted ;-) ). Can it works? Antoine

2 1

Re: double rounding in xtime_diff()?
by Marc Lehmann Oct. 13, 1998

Oct. 13, 1998

On Mon, Oct 12, 1998 at 11:24:06AM +0100, Markus Kuhn wrote: > That's very interesting. Under Linux/Pentium_II (cpu=686, model=3, > vendor_id=GenuineIntel, stepping=4, gcc 2.7.2.3) the effect does not > show up immediately. I had to enforce using the software FP-library with > gcc -msoft-float to reproduce this effect, because without this option > with the hardware FPU I get the correct result (and this is apparently > not thanks to Intel's internal 80-bit arithmetic, because I did use gcc > -ffloat-store to enforce 64-bit rounding). Have you looked at the actual assemby output? x86 is the worst platform to "prove" something about double arithmetic. Unless you set the cpu to double rounding mode (say, using __setfpucw), therefore invalidating long double, nothing will help. -ffloat-store does not do what you want in every case. > There seem to be interesting differences between IEEE and IEEE. No, but between IEEE and x86 ;( > A somewhat related question: Given a floating-point value X, > is there in C9X a portable way to get the next smaller and the You could (in C90 as well) try to mess around with frexp/ldexp and/or scalb. The draft c9x standard (as well as xopen-extended) seems to contain a "nextafter" function: nextafter (x, y): Return X + epsilon if X < Y, X - epsilon if X > Y. -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg(a)goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | |

1 0

leap.yp.to
by D. J. Bernstein Oct. 13, 1998

Oct. 13, 1998

As an experiment I've set up a TXT record in DNS for leap.yp.to with a year-by-year history of leap seconds since 1972. On a UNIX machine try nslookup -type=txt leap.yp.to or dig txt leap.yp.to It's easy to do this automatically every May and November, and to convert the results to libtai's /etc/leapsecs.dat format. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html

1 0

Re: double rounding in xtime_diff()?
by Markus Kuhn Oct. 13, 1998

Oct. 13, 1998

Paul Eggert wrote on 1998-10-12 19:57 UTC: > > ``non-pathological'' = year range -9999 .. +9999 > > OK, then here's a non-pathological example of a double-rounding error: > > 1970-01-01 00:00:01.851401618 UTC > - 1970-01-01 00:00:00.000000000 UTC > > On the host that I'm talking about (sparc, IEEE, round-to-even) > your xtime_diff implementation yields > 1.851401618000000137698179969447664916515350341796875 exactly, whereas > 1.8514016179999999156535750444163568317890167236328125, which is also > exactly representable as an IEEE double, is closer to the correct answer. That's very interesting. Under Linux/Pentium_II (cpu=686, model=3, vendor_id=GenuineIntel, stepping=4, gcc 2.7.2.3) the effect does not show up immediately. I had to enforce using the software FP-library with gcc -msoft-float to reproduce this effect, because without this option with the hardware FPU I get the correct result (and this is apparently not thanks to Intel's internal 80-bit arithmetic, because I did use gcc -ffloat-store to enforce 64-bit rounding). There seem to be interesting differences between IEEE and IEEE. ----------------------------------------------------------------------- #include <stdio.h> typedef long long int_fast64_t; typedef long int_fast32_t; struct xtime { int_fast64_t sec; int_fast32_t nsec; }; double xtime_diff(struct xtime t1, struct xtime t2) { if (t1.nsec > 1000000000) t1.nsec = 1000000000; if (t2.nsec > 1000000000) t2.nsec = 1000000000; return (t1.sec - t2.sec) + (t1.nsec - t2.nsec) / 1.0e9; } int main() { struct xtime t1 = { 1, 851401618 }, t2 = { 0, 0 }; double d; d = xtime_diff(t1, t2); printf("%.60f\n", d); return 0; } ----------------------------------------------------------------------- Suggestions for a better portable implementation? A somewhat related question: Given a floating-point value X, is there in C9X a portable way to get the next smaller and the next larger floating point value? Something like the Double'Succ(X) and Double'Pred(X) built-in function attributes available in Ada <http://wuarchive.wustl.edu/languages/ada/userdocs/docadalt/rm95/0305.htm>. This might be very useful to write portable C code that is guaranteed to deliver the closest value. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

2 1

Re: xtime/libtai/"right"
by Nathan Myers Oct. 12, 1998

Oct. 12, 1998

> But as noted by Bradley and David before, this is not a problem when > you are only talking about inode times. Since when are we only talking about inode times? Part of the problem with tm/time_t is that it works ok for inode times but not for other equally-important uses. The problem with the mktime model is that conversions between civil time and timestamps can result in 2, 1, or <1 valid conversions, and neither the user (before the conversion) nor the library is equipped to favor one result over another, or deal properly with nonexistent times. mktime offers no interface for the algorithm to report what it finds, so it must falsify its results. After a conversion, if all the results are exposed the client has the information necessary to make an informed choice. I hope that any interface offered to improve on mktime will expose the information needed to write reliable code. If it is also "nice" for the common ranges where there actually is a one-to-one mapping, that's a bonus. Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

1 0

Re: xtime/libtai/"right"
by Bradley White Oct. 12, 1998

Oct. 12, 1998

>> I think if we all stipulate that some form of "display UTC" is the >> only representation that should be stored or forwarded, > You expect high-volume logging tools and network servers to convert > every timestamp to year-month-day-hour-minute-second-subsecond? I only expect entities that wish to exchange timestamps with other entities to convert them to a "display UTC" equivalent representation, which does not imply such a full breakdown. It is up to the protocol designer to choose the "display UTC" representation, and it is up to the local system to choose the timestamp representation. Both parties will undoubtedly want to make choices that simplify any conversions. [It would also be possible for the protocol to negotiate a mutually acceptable representation to avoid any conversions, but everyone should accept the "display UTC" equivalent.] > What exactly is the benefit of these conversions? The benefit is the separation of local and remote representations. Might I liken it to exchanging floating point values? > you're kidding yourself if > you expect UNIX filesystems to start storing inode times in that format. I only expect them to store something equivalent to "display UTC". [POSIX time_t's fail to represent leap seconds. People seem to dislike struct xtime because of the ability to represent bogus leap seconds. TAI requires a leap-second table.] So choose any flavour you like locally, but don't force that choice upon those you communicate with. And recognize your shortcomings (for example, POSIX-time_t based file systems screw up file time orderings during leap seconds).

4 3