August 2004 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

strftime %y and negative years
by Paul Eggert Sept. 10, 2004

Sept. 10, 2004

"Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > ...the suggested change to strftime is trying to get %y to > produce the "year within the century" as output. Yes, that's correct: it's trying to produce the year modulo 100. > But the latest IEEE Std 1003.1 calls for... > > %y Replaced by the last two digits of the year as a decimal > number [00,99]. Read literally, this would have undefined behavior for the years -9 through 9 (since they don't have two digits), and would generate "10" for the year -10, and so forth, which obviously disagrees with the proposed "year modulo 100" semantics. However, I just checked 3 implementations and found that nobody obeys the literal behavior for years before -9, that there's disagreement about negative single-digit years, and that at least one traditional Unix implementation mishandles years before 1900 (not too surprising, since the Unix Version 7 ctime allowed only years in the range 1900..2099). Here's what I found. year (i.e., glibc 2.2.5 OpenBSD 3.4 Solaris 9 tm_year-1900) (Debian patch 112874-29 2.2.5-11.5) (64-bit sparc) -101 99 -1 0/ -100 00 00 00 -99 01 -99 '' (i.e., two apostrophes) ... -2 98 -2 0. -1 99 -1 0/ 0 00 00 00 1 01 01 '' ... 9 09 09 '/ 10 10 10 '0 11 11 11 (' ... 99 99 99 0/ 100 00 00 00 101 01 01 '' ... 1899 99 99 0/ 1900 00 00 00 ... The implementations agreed for years after 1899, until they got to the year 2**31: 2**31 - 1 47 47 47 2**31 48 -48 48 2**31 + 1 49 -47 49 2**31 + 2 50 -46 50 .... 2**31 + 1897 45 -51 45 2**31 + 1898 46 -50 46 2**31 + 1899 47 -49 47 So it appears that, in practice, the behavior of strftime %y is undefined when tm_year is negative, or when tm_year+1900 exceeds INT_MAX. I don't know whether the standards committee would consider all this to be a bug in the standard or in the implementations, but here's what I think. The Solaris behavior is clearly buggy for years before 1900. The OpenBSD behavior is clearly buggy for years after 2**31 - 1. For years before 0, I suppose that it's debatable between OpenBSD 3.4 and glibc 2.2.5. However, I'd say that the glibc 2.2.5 behavior is cleaner, since it's more regular, it always outputs two bytes, and it doesn't output "-". PS. Disclaimer: I wrote that part of glibc 2.2.5 so my opinion is hardly impartial. PPS. Ironic, isn't it? The consensus is that new code shouldn't use ctime, as it's obsolete and is undefined for years out of the traditional range, and that new code should use strftime. But in practice, strftime has problems too. PPPS. I'll CC: this to the tz mailing list to see if anybody else has experiences with other implementations in this area, or strong opinions on the subject.

3 4

FW: Definition of time_t changed from signed to unsigned...
by Olson, Arthur David (NIH/NCI) Aug. 20, 2004

Aug. 20, 2004

Susan Richards is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Susan Richards [mailto:cj_richards@hotmail.com] Sent: Wednesday, August 18, 2004 12:58 PM To: clive(a)demon.net; guy(a)alum.mit.edu Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Definition of time_t changed from signed to unsigned... Hello All, I have another (potentially stupid) question regarding the interaction of NTP, leap seconds and the timezone database: As I've been going through the TZ code, I've seen the leap correction code. It appears that the adjustment for leap seconds is made when converting the UTC system time (which includes leap seconds) to POSIX (which does not) or visa versa. So my understanding is:- UTC - includes leap seconds POSIX - no leap seconds included. Is this correct? If my system is maintaining UTC (as set by some NTP server), and running the timezone database code, then are my following assumptions correct: 1) The result of calling time(0) is UTC (as maintained by NTP) and does include leap seconds. 2) The date & time displayed using "date" also takes into account leap seconds. 3) If I want to report POSIX time, I need to call time2posix(). Thanks for your time. Chris. From: "Clive D.W. Feather" <clive(a)demon.net> To: Guy Harris <guy(a)alum.mit.edu> CC: Chris Richards <cj_richards(a)hotmail.com>, Tz <tz(a)lecserver.nci.nih.gov> Subject: Re: Definition of time_t changed from signed to unsigned... Date: Tue, 20 Jul 2004 09:30:31 +0100 Guy Harris said: >>> If you can, I'd change the time_t typedef in the OS. >> Changing an OS-supplied definition is EXTREMELY DUMB. You're risking >> breaking the OS interfaces. > When he said "I am in the process of upgrading the kernel version on a > platform that I > work on.", it sounded as if he might be one of the developers *of* that > platform In which case it's a very different kettle of fish, I agree. I read the original thread as suggesting just changing the header file available to user code and reacted accordingly - that remains extremely dumb. Changing the OS's own definitions is, of course, completely different. If I've reacted over nothing, I apologise to all concerned. -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee(r) Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 5

Re: The year before the year 1
by Paul Eggert Aug. 19, 2004

Aug. 19, 2004

"Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > it's a localtime/gmtime issue (how to set the value of tm_year for > given time_t inputs). In any event...can you point me at chapter on > verse from the C standard on this? The C standard says that the semantics of tm_year is "years since 1900". It gives no normal range limit (unlike other members like tm_mon, where it lists a normal range limit of [0,11]), so presumably the valid values for tm_year are INT_MIN..INT_MAX. However, the standard has no explicit statement that tm_year == -1 stands for 1899, and I guess that one could argue that the word "since" implies a nonnegative value and that the behavior is undefined when tm_year is negative. However, I don't know of any implementation where -1 stands for anything other than 1899 (the only obvious value). If we assume this, then -2 stands for 1898, ..., -1899 stands for the year 1, and -1900 stands for the year 0 (or the year 1 B.C., if you prefer the Venerable Bede's notation). This is true on all implementations that I know of, at least as far as localtime/gmtime goes (typically on 64-bit hosts). For strftime the issue is not so clear: please see my next message.

1 0

Re: Definition of time_t changed from signed to unsigned...
by Bradley White Aug. 19, 2004

Aug. 19, 2004

Susan (Chris?) Richards asked: > As I've been going through the TZ code, I've seen the leap correction code. > It appears that the adjustment for leap seconds is made when converting the > UTC system time (which includes leap seconds) to POSIX (which does not) or > visa versa. The adjustment for leap seconds is made when converting a time_t to a struct tm. > So my understanding is:- > UTC - includes leap seconds An ado "right" time_t includes leap seconds (i.e., it keeps ticking through leap events). > POSIX - no leap seconds included. A POSIX time_t uses 86400-second days (i.e., the system time must be adjusted during leap events). > If my system is maintaining UTC (as set by some NTP server), and running > the timezone database code, then are my following assumptions correct: > > 1) The result of calling time(0) is UTC (as maintained by NTP) and does > include leap seconds. If you are running in "right" mode, time(0) returns a "right" time_t. "posix" mode, of course, results in a POSIX time_t. Given that NTP uses POSIX-like timestamps, a call to time2posix() needs to be added to NTP in order for it to correctly synchronize an ado "right" system (after which it can also ignore leap warnings). > 2) The date & time displayed using "date" also takes into account leap > seconds. "date" always displays the civil time. A non-"right" system will show a discontinuity over a leap event, however. > 3) If I want to report POSIX time, I need to call time2posix(). Correct ... time2posix() always returns a POSIX time_t whether you are running in "right" mode or not. Bradley

1 0

ftp://elsie.nci.nih.gov/pub/ doesn't work
by Frédéric L. W. Meunier Aug. 12, 2004

Aug. 12, 2004

I don't know why, but I'm assuming it's because it now rejects connectiong from hosts that don't resolve. Please let me know about any mirrors. -- http://www.pervalidus.net/contact.html

3 2

proposed patch to difftime.c and Makefile for tz code
by Paul Eggert Aug. 11, 2004

Aug. 11, 2004

Here's a proposed patch to difftime.c and Makefile to reflect all the recent back-and-forth between Clive D.W. Feather and myself. The main practical import of this patch is the avoidance of a double-rounding bug on hosts with 64-bit time_t and 64-bit 'long double', but it also fixes some much-bigger errors on unusual hosts that have holes in their integer representations. Thanks, Clive! *** Makefile 2004/08/11 15:59:05 2004.3 --- Makefile 2004/08/11 20:30:07 2004.3.0.1 *************** LDLIBS= *** 87,105 **** # Add the following to the end of the "CFLAGS=" line as needed. # -Dconst= if `const' does not work (SunOS 4.x cc, OSF1 V5.0 cc) # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS # -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard (Solaris 8). ! # -DHAVE_LONG_DOUBLE=1 if your compiler supports the `long double' type # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) # -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD) # -DHAVE_SETTIMEOFDAY=3 if settimeofday ignores 2nd arg (4.4BSD) # -DHAVE_STRERROR=0 if your system lacks the strerror function # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if your compiler lacks a "sys/stat.h" # -DHAVE_SYS_WAIT_H=0 if your compiler lacks a "sys/wait.h" # -DLOCALE_HOME=\"path\" if locales are in "path", not "/usr/lib/locale" # -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?) # -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h" --- 87,110 ---- # Add the following to the end of the "CFLAGS=" line as needed. # -Dconst= if `const' does not work (SunOS 4.x cc, OSF1 V5.0 cc) + # -Duintmax='unsigned long long int' if your pre-C99 compiler has such a type # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS # -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard (Solaris 8). ! # -DHAVE_LONG_DOUBLE=1 if your pre-C89 compiler has the `long double' type # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) # -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD) # -DHAVE_SETTIMEOFDAY=3 if settimeofday ignores 2nd arg (4.4BSD) + # -DHAVE_STDINT_H=1 if your pre-C99 compiler has a "stdint.h" # -DHAVE_STRERROR=0 if your system lacks the strerror function # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if your compiler lacks a "sys/stat.h" # -DHAVE_SYS_WAIT_H=0 if your compiler lacks a "sys/wait.h" + # -DINTMAX_MAX=9223372036854775807 (or to the greatest signed integer, + # whatever it is) if your compiler lacks INTMAX_MAX, and if LLONG_MAX + # (or LONG_MAX, if LLONG_MAX is not defined) is not the greatest # -DLOCALE_HOME=\"path\" if locales are in "path", not "/usr/lib/locale" # -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?) # -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h" *** difftime.c 2002/01/28 15:36:25 2002.2 --- difftime.c 2004/08/11 20:13:16 2002.2.0.3 *************** static char elsieid[] = "@(#)difftime.c *** 14,83 **** #include "private.h" /* ! ** Algorithm courtesy Paul Eggert (eggert(a)twinsun.com) */ ! #ifdef HAVE_LONG_DOUBLE ! #define long_double long double ! #endif /* defined HAVE_LONG_DOUBLE */ #ifndef HAVE_LONG_DOUBLE ! #define long_double double #endif /* !defined HAVE_LONG_DOUBLE */ double difftime(time1, time0) ! const time_t time1; ! const time_t time0; { ! time_t delta; ! time_t hibit; - { - time_t tt; - double d; - long_double ld; - - if (sizeof tt < sizeof d) - return (double) time1 - (double) time0; - if (sizeof tt < sizeof ld) - return (long_double) time1 - (long_double) time0; - } - if (time1 < time0) - return -difftime(time0, time1); - /* - ** As much as possible, avoid loss of precision - ** by computing the difference before converting to double. - */ - delta = time1 - time0; - if (delta >= 0) - return delta; /* ! ** Repair delta overflow. */ ! hibit = (~ (time_t) 0) << (TYPE_BIT(time_t) - 1); /* ! ** The following expression rounds twice, which means ! ** the result may not be the closest to the true answer. ! ** For example, suppose time_t is 64-bit signed int, ! ** long_double is IEEE 754 double with default rounding, ! ** time1 = 9223372036854775807 and time0 = -1536. ! ** Then the true difference is 9223372036854777343, ! ** which rounds to 9223372036854777856 ! ** with a total error of 513. ! ** But delta overflows to -9223372036854774273, ! ** which rounds to -9223372036854774784, and correcting ! ** this by subtracting 2 * (long_double) hibit ! ** (i.e. by adding 2**64 = 18446744073709551616) ! ** yields 9223372036854776832, which ! ** rounds to 9223372036854775808 ! ** with a total error of 1535 instead. ! ** This problem occurs only with very large differences. ! ** It's too painful to fix this portably. ! ** We are not alone in this problem; ! ** some C compilers round twice when converting ! ** large unsigned types to small floating types, ! ** so if time_t is unsigned the "return delta" above ! ** has the same double-rounding problem with those compilers. */ ! return delta - 2 * (long_double) hibit; } --- 14,175 ---- #include "private.h" /* ! ** Algorithm courtesy Paul Eggert (eggert(a)cs.ucla.edu) ! ** ! ** Most other code assumes that time_t is an integer type without ! ** padding bits, and that integer arithmetic is modular two's ! ** complement without overflow traps, but (just for fun) this works ! ** even if time_t is an integer type with padding bits, or a real ! ** floating type, and it works even if signed integer overflow ! ** has undefined behavior. */ ! #include <float.h> ! ! #define TYPE_FLOATING(type) ((type) 0.4 != 0) ! ! #if !defined HAVE_LONG_DOUBLE && defined __STDC__ ! #define HAVE_LONG_DOUBLE 1 ! #endif /* !defined HAVE_LONG_DOUBLE && defined __STDC__ */ #ifndef HAVE_LONG_DOUBLE ! #define HAVE_LONG_DOUBLE 0 #endif /* !defined HAVE_LONG_DOUBLE */ + #if HAVE_LONG_DOUBLE + #define long_double long double + #endif /* HAVE_LONG_DOUBLE */ + #if !HAVE_LONG_DOUBLE + #define long_double double + #endif /* !HAVE_LONG_DOUBLE */ + + #ifndef HAVE_STDINT_H + #define HAVE_STDINT_H (199901L <= __STDC_VERSION__) + #endif /* !defined HAVE_STDINT_H */ + + #if HAVE_STDINT_H + #include <stdint.h> + #define uintmax uintmax_t + #endif /* HAVE_STDINT_H */ + #if !defined uintmax && defined ULLONG_MAX + #define uintmax unsigned long long int + #endif /* !defined uintmax && defined ULLONG_MAX */ + #ifndef uintmax + #define uintmax unsigned long int + #endif /* defined uintmax */ + + #ifndef UINTMAX_MAX + #define UINTMAX_MAX ((uintmax) -1) + #endif /* !defined UINTMAX_MAX */ + + #if !defined INTMAX_MAX && defined LLONG_MAX + #define INTMAX_MAX LLONG_MAX + #endif /* !defined INTMAX_MAX && defined LLONG_MAX */ + #ifndef INTMAX_MAX + #define INTMAX_MAX LONG_MAX + #endif /* !defined INTMAX_MAX */ + double difftime(time1, time0) ! time_t time1; ! time_t time0; { ! int time1_is_smaller; ! double delta; /* ! ** Use floating point if there should be no double-rounding error. ! ** However, avoid long double if it must be wider than needed, ! ** as it's sometimes much more expensive in these cases ! ** (e.g., 64-bit sparc). */ ! if (TYPE_BIT(time_t) <= DBL_MANT_DIG ! || (TYPE_FLOATING(time_t) ! && sizeof(time_t) < sizeof(long_double))) { ! double t1 = time1; ! double t0 = time0; ! return t1 - t0; ! } ! if ((TYPE_BIT(time_t) <= LDBL_MANT_DIG ! && (TYPE_BIT(time_t) == LDBL_MANT_DIG ! || (TYPE_SIGNED(time_t) && UINTMAX_MAX / 2 < INTMAX_MAX))) ! || TYPE_FLOATING(time_t)) { ! long_double t1 = time1; ! long_double t0 = time0; ! return t1 - t0; ! } ! ! time1_is_smaller = time1 < time0; ! if (time1_is_smaller) { ! time_t t = time1; ! time0 = time1; ! time1 = t; ! } ! /* ! ** Now time0 <= time1, and time_t is an integer type. ! ** Optimize the common special cases where time_t is unsigned, ! ** or can be converted to uintmax without losing information. */ ! if (! TYPE_SIGNED(time_t)) ! delta = time1 - time0; ! else { ! uintmax t1 = time1; ! uintmax t0 = time0; ! uintmax dt = t1 - t0; ! delta = dt; ! if (UINTMAX_MAX / 2 < INTMAX_MAX) { ! /* ! ** uintmax has padding bits, and time_t is signed. ! ** Check for overflow: compare dt/2 to (time1/2 - ! ** time0/2). Overflow occurred if they differ by ! ** more than a small slop. ! ** ! ** Thanks to Clive D.W. Feather for detailed technical ! ** advice about hosts with padding bits. ! */ ! uintmax hdt = dt / 2; ! time_t ht1 = time1 / 2; ! time_t ht0 = time0 / 2; ! time_t dht = ht1 - ht0; ! /* ! ** "h" here means half. By range analysis, we have: ! ** -0.5 <= ht1 - time1/2 <= 0.5 ! ** -0.5 <= ht0 - time0/2 <= 0.5 ! ** -1.0 <= dht - (time1 - time0)/2 <= 1.0 ! ** If overflow has not occurred, we also have: ! ** -0.5 <= hdt - (time1 - time0)/2 <= 0 ! ** -1.0 <= dht - hdt <= 1.5 ! ** and since dht - hdt is an integer, we also have: ! ** -1 <= dht - hdt <= 1 ! ** or equivalently: ! ** 0 <= dht - hdt + 1 <= 2 ! ** In the above analysis, all the operators have ! ** their exact mathematical semantics, not C semantics. ! ** However, dht - hdt + 1 is unsigned in C, ! ** so it need not be compared to zero. ! */ ! if (2 < dht - hdt + 1) { ! /* ! ** Repair delta overflow. ! ** ! ** The following expression contains a second ! ** rounding, so the result may not be the ! ** closest to the true answer. This problem ! ** occurs only with very large differences, ! ** It's too painful to fix this portably. ! ** We are not alone in this problem; some C ! ** compilers round twice when converting ! ** large unsigned types to small floating ! ** types, so if time_t is unsigned the ! ** "delta = dt" above has the same ! ** double-rounding problem with those ! ** compilers. ! */ ! long_double hibit = ~(UINTMAX_MAX / 2); ! delta = dt + 2 * hibit; ! } ! } ! } ! ! return time1_is_smaller ? -delta : delta; }

1 0

The year before the year 1
by Olson, Arthur David (NIH/NCI) Aug. 11, 2004

Aug. 11, 2004

One of Paul's documentation changes that I left out of the update was... +The year before the year 1 is the year 0, the year before that is +the year \-1, and so forth. If I recall correctly, there's no year zero: the sequence (going backward) is... 3 AD, 2 AD, 1 AD, 1 BC, 2 BC, 3 BC... ...or, for "Common Era" fans... 3 CE, 2 CE, 1 CE, 1 BCE, 2 BCE, 3 BCE.. Have our standard-making friends said anything on the matter? --ado

3 2

Tzcode2004c.tar.gz
by Olson, Arthur David (NIH/NCI) Aug. 11, 2004

Aug. 11, 2004

The file... ftp://elsie.nci.nih.gov/tzcode2004c.tar.gz ...is now available; this includes the asctime-related changes circulated on the time zone mailing list last week as well as (variants of) some of the documentation changes suggested by Paul Eggert. No new data tarball has been made available since none of the data tarball components have changed. --ado

1 0

Difftime code
by Clive D. W. Feather Aug. 10, 2004

Aug. 10, 2004

Okay, I've looked at the problem a bit. I also note that there's some portability problems in the code in 2004b. In particular, if time_t is a signed integer type then the calculation of delta can involve undefined behaviour; you cannot assume twos-complement unflagged wrap-around in signed integer types. time_t has to be either an integer type or a real-floating type [C99 allows it to be a complex-floating type, but POSIX doesn't]. We can easily distinguish these cases: if ((time_t) 0.2 != (time_t) 0.4) // It's a real-floating type else // It's an integer type If it's real-floating, then: return (long double) time1 - time0; is as accurate as you can get: the subtraction is done in long double (the conversion to this is lossless) and the rounding to double happens at the end. If it's integer, it's a bit harder; I'll assume for simplicity that time1>time0. if (time0 >= 0 || time1 < 0) return time1 - time0; In this case, the subtraction won't overflow; if the result is representable, it'll be rounded at the end. In the remaining case, a simple subtraction could overflow and you're in trouble. So we need to find the "top type": * on a C99 implementation, this is uintmax_t; * on a C89 implementation, this is unsigned long; * on non-conforming implementations you have a problem, but the most likely case is unsigned long or unsigned long long. #if __STDC__ == 1 && __STDC_VERSION__ >= 199901L #define HAVE_UINTMAX_T #endif #ifdef HAVE_UINTMAX_T #include <stdint.h> typedef uintmax_t top_type; #else #ifdef HAVE_LONG_LONG typedef unsigned long long top_type; #else typedef unsigned long top_type; #endif #endif This code works correctly on C89 and C99 conforming implementations, but you may have to tune it for others. If we now cast the two values to (top_type) and subtract, we get a value which is either: time1 - time0 OR time1 - time0 - BASIS (BASIS is 2 to the power N, where N is the number of bits in top_type). The latter case can only happen if top_type has the same number of *value* bits as time_t and so has the same maximum value, *and* the subtraction overflows. time_t s4 = time1 / 4 - time0 / 4; top_type dt = (top_type) time1 - (top_type) time0; top_type t4 = dt / 4; At this point, t4 is either approximately equal to s4, in which case dt is correct, or the right answer is dt + BASIS, in which case t4 is approximately s4 - BASIS / 4. So: if (t4 > s4 - (top_type)-1 / 8) return dt; So now we can't stay in integer types to calculate the entire value. Rather, we need to do dt + BASIS in long double. top_type halfBASIS = (top_type)-1 / 2 + 1; return 2.0L * halfBASIS + dt; I'm not in a position to do a full analysis, but let me note that we're adding two positive values, so you don't have the issues you do with subtraction and the addition can only lose 1ulp of precision. Furthermore, on a binary machine the first operand can be represented exactly. So, putting that all together and making some cosmetic changes and minor optimisations: #if __STDC__ == 1 // and the implementation isn't lying about this #if __STDC_VERSION >= 199901L #include <stdint.h> typedef uintmax_t top_type; #else typedef unsigned long top_type; #endif typedef long double long_double; #else // You'll have to fill this in using your own portability guidelines typedef ???? top_type; // The widest range unsigned integer type typedef ???? long_double; // The widest range floating-point type #endif double difftime (const time_t time1, const time_t time0) { time_t s4; top_type dt; if ((time_t) 0.2 != (time_t) 0.4) return (long_double) time1 - time0; if (time1 < time0) return -difftime (time0, time1); if (time0 >= 0 || time1 < 0) return time1 - time0; s4 = (time1 >> 2) - time0 / 4; // time0 < 0, so >> is a bad idea dt = (top_type) time1 - (top_type) time0; if ((dt >> 2) > s4 - ((top_type)-1 >> 3)) return dt; return (long_double) 2 * ~((top_type)-1 >> 1) + dt; } If you don't like this approach, then I have one other suggestion. Rather than using sizeof as a placeholder for the precision of various types, you can use the values FLT_RADIX and LDBL_MANT_DIG (in <float.h>) to calculate the largest integer that can be represented exactly in long double: static long double maxLDint = 0.0; if (maxLDint < 100.0) { int i; for (i = 0; i < LDBL_MANT_DIG; i++) maxLDint = maxLDint * FLT_RADIX + (FLT_RADIX - 1); } But you still need to address some of your other bugs in your code. -- Clive D.W. Feather | Internet Expert | Work: <clive(a)demon.net> Tel: +44 20 8495 6138 | Demon Internet | Home: <clive(a)davros.org> Fax: +44 870 051 9937 | Thus plc | Web: <http://www.davros.org> Please reply to the Reply-To address, which is: <clive(a)demon.net>

3 8

RE: Proposed asctime-related changes
by Olson, Arthur David (NIH/NCI) Aug. 10, 2004

Aug. 10, 2004

> First, GCC warns about zdump.c's new signed-versus-unsigned comparisons "timeptr->tm_wday >= sizeof ...." and similarly for tm_mon. > The comparisons aren't needed here, since the values are guaranteed to be in range, so the easiest fix is to remove them. The packaged versions of localtime and gmtime always return in-range values for tm_wday and tm_mon. However, zdump.c might be compiled with a version of localtime or gmtime that does something evil, so defensive programming may be in order. Casts along the lines shown below should do the trick. --ado if (timeptr->tm_wday < 0 || timeptr->tm_wday >= (int) (sizeof wday_name / sizeof wday_name[0])) wn = "???"; else wn = wday_name[timeptr->tm_wday]; if (timeptr->tm_mon < 0 || timeptr->tm_mon >= (int) (sizeof mon_name / sizeof mon_name[0])) mn = "???"; else mn = mon_name[timeptr->tm_mon];

3 5

FW: Chinese timezones do not observe DST
by Olson, Arthur David (NIH/NCI) Aug. 9, 2004

Aug. 9, 2004

Since sending this message, Alexandru Pulbere has been added to the time zone mailing list. --ado _____ From: Pulbere, Alexandru [mailto:Alexandru.Pulbere@cognos.com] Sent: Thursday, August 05, 2004 6:56 PM To: tz(a)lecserver.nci.nih.gov Subject: Chinese timezones do not observe DST I noticed that the timezone description for chinese timezones use DST. Aparently the chinese governament stopped using DST in 1992. To fix the problem I changed my copy asia file and regenerated ICU4J resources (my copy). # China # From Guy Harris: # People's Republic of China. Yes, they really have only one time zone. # From Bob Devine (1988-01-28): # No they don't. See TIME mag, 1986-02-17 p.52. Even though # China is across 4 physical time zones, before Feb 1, 1986 only the # Peking (Bejing) time zone was recognized. Since that date, China # has two of 'em -- Peking's and Urumqi (named after the capital of # the Xinjiang Uyghur Autonomous Region). I don't know about DST for it. # # . . .I just deleted the DST table and this editor makes it too # painful to suck in another copy.. So, here is what I have for # DST start/end dates for Peking's time zone (info from AP): # # 1986 May 4 - Sept 14 # 1987 mid-April - ?? # From U. S. Naval Observatory (1989-01-19): # CHINA 8 H AHEAD OF UTC ALL OF CHINA, INCL TAIWAN # CHINA 9 H AHEAD OF UTC APR 17 - SEP 10 # From Paul Eggert <eggert(a)twinsun.com> (1995-12-19): # Shanks writes that China has had a single time zone since 1980 May 1, # observing summer DST from 1986 through 1991; this contradicts Devine's # note about Time magazine, though apparently _something_ happened in 1986. # Go with Shanks for now. I made up names for the other pre-1980 time zones. # From Shanks: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Shang 1940 only - Jun 3 0:00 1:00 D Rule Shang 1940 1941 - Oct 1 0:00 0 S Rule Shang 1941 only - Mar 16 0:00 1:00 D Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D # # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # From Anthony Fok (2001-12-20): # BTW, I did some research on-line and found some info regarding these five # historic timezones from some Taiwan websites. And yes, there are official # Chinese names for these locales (before 1949): # Changbai Time ("Long-white Time", Long-white = Heilongjiang area) 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 1992 8:00 - CST # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT 1992 8:00 - CST # 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 1992 8:00 - CST # 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 1992 8:00 - CST # 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 1992 8:00 - CST # Hong Kong (Xianggang) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule HK 1946 only - Apr 20 3:30 1:00 S Rule HK 1946 only - Dec 1 3:30 0 - Rule HK 1947 only - Apr 13 3:30 1:00 S Rule HK 1947 only - Dec 30 3:30 0 - Rule HK 1948 only - May 2 3:30 1:00 S Rule HK 1948 1952 - Oct lastSun 3:30 0 - Rule HK 1949 1953 - Apr Sun>=1 3:30 1:00 S Rule HK 1953 only - Nov 1 3:30 0 - Rule HK 1954 1964 - Mar Sun>=18 3:30 1:00 S Rule HK 1954 only - Oct 31 3:30 0 - Rule HK 1955 1964 - Nov Sun>=1 3:30 0 - Rule HK 1965 1977 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1977 - Oct Sun>=16 3:30 0 - Rule HK 1979 1980 - May Sun>=8 3:30 1:00 S Rule HK 1979 1980 - Oct Sun>=16 3:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Hong_Kong 7:36:36 - LMT 1904 Oct 30 8:00 HK HK%sT 2002 8:00 - CST ############################################################################ ### # Taiwan # Shanks writes that Taiwan observed DST during 1945, when it # was still controlled by Japan. This is hard to believe, but we don't # have any other information. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Taiwan 1945 1951 - May 1 0:00 1:00 D Rule Taiwan 1945 1951 - Oct 1 0:00 0 S Rule Taiwan 1952 only - Mar 1 0:00 1:00 D Rule Taiwan 1952 1954 - Nov 1 0:00 0 S Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D Rule Taiwan 1955 1961 - Oct 1 0:00 0 S Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D Rule Taiwan 1974 1975 - Oct 1 0:00 0 S Rule Taiwan 1980 only - Jun 30 0:00 1:00 D Rule Taiwan 1980 only - Sep 30 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Taipei 8:06:00 - LMT 1896 # or Taibei or T'ai-pei 8:00 Taiwan C%sT 1992 8:00 - CST # Macau (Macao, Aomen) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Macau 1961 1962 - Mar Sun>=16 3:30 1:00 S Rule Macau 1961 1964 - Nov Sun>=1 3:30 0 - Rule Macau 1963 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1964 only - Mar Sun>=16 3:30 1:00 S Rule Macau 1965 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1965 only - Oct 31 0:00 0 - Rule Macau 1966 1971 - Apr Sun>=16 3:30 1:00 S Rule Macau 1966 1971 - Oct Sun>=16 3:30 0 - Rule Macau 1972 1974 - Apr Sun>=15 0:00 1:00 S Rule Macau 1972 1973 - Oct Sun>=15 0:00 0 - Rule Macau 1974 1977 - Oct Sun>=15 3:30 0 - Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 - CST This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.

2 1

Chinese timezones do not observe DST
by Pulbere, Alexandru Aug. 5, 2004

Aug. 5, 2004

I noticed that the timezone description for chinese timezones use DST. Aparently the chinese governament stopped using DST in 1992. To fix the problem I changed my copy asia file and regenerated ICU4J resources (my copy). # China # From Guy Harris: # People's Republic of China. Yes, they really have only one time zone. # From Bob Devine (1988-01-28): # No they don't. See TIME mag, 1986-02-17 p.52. Even though # China is across 4 physical time zones, before Feb 1, 1986 only the # Peking (Bejing) time zone was recognized. Since that date, China # has two of 'em -- Peking's and Urumqi (named after the capital of # the Xinjiang Uyghur Autonomous Region). I don't know about DST for it. # # . . .I just deleted the DST table and this editor makes it too # painful to suck in another copy.. So, here is what I have for # DST start/end dates for Peking's time zone (info from AP): # # 1986 May 4 - Sept 14 # 1987 mid-April - ?? # From U. S. Naval Observatory (1989-01-19): # CHINA 8 H AHEAD OF UTC ALL OF CHINA, INCL TAIWAN # CHINA 9 H AHEAD OF UTC APR 17 - SEP 10 # From Paul Eggert <eggert(a)twinsun.com> (1995-12-19): # Shanks writes that China has had a single time zone since 1980 May 1, # observing summer DST from 1986 through 1991; this contradicts Devine's # note about Time magazine, though apparently _something_ happened in 1986. # Go with Shanks for now. I made up names for the other pre-1980 time zones. # From Shanks: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Shang 1940 only - Jun 3 0:00 1:00 D Rule Shang 1940 1941 - Oct 1 0:00 0 S Rule Shang 1941 only - Mar 16 0:00 1:00 D Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D # # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # From Anthony Fok (2001-12-20): # BTW, I did some research on-line and found some info regarding these five # historic timezones from some Taiwan websites. And yes, there are official # Chinese names for these locales (before 1949): # Changbai Time ("Long-white Time", Long-white = Heilongjiang area) 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 1992 8:00 - CST # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT 1992 8:00 - CST # 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 1992 8:00 - CST # 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 1992 8:00 - CST # 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 1992 8:00 - CST # Hong Kong (Xianggang) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule HK 1946 only - Apr 20 3:30 1:00 S Rule HK 1946 only - Dec 1 3:30 0 - Rule HK 1947 only - Apr 13 3:30 1:00 S Rule HK 1947 only - Dec 30 3:30 0 - Rule HK 1948 only - May 2 3:30 1:00 S Rule HK 1948 1952 - Oct lastSun 3:30 0 - Rule HK 1949 1953 - Apr Sun>=1 3:30 1:00 S Rule HK 1953 only - Nov 1 3:30 0 - Rule HK 1954 1964 - Mar Sun>=18 3:30 1:00 S Rule HK 1954 only - Oct 31 3:30 0 - Rule HK 1955 1964 - Nov Sun>=1 3:30 0 - Rule HK 1965 1977 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1977 - Oct Sun>=16 3:30 0 - Rule HK 1979 1980 - May Sun>=8 3:30 1:00 S Rule HK 1979 1980 - Oct Sun>=16 3:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Hong_Kong 7:36:36 - LMT 1904 Oct 30 8:00 HK HK%sT 2002 8:00 - CST ######################################################################## ####### # Taiwan # Shanks writes that Taiwan observed DST during 1945, when it # was still controlled by Japan. This is hard to believe, but we don't # have any other information. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Taiwan 1945 1951 - May 1 0:00 1:00 D Rule Taiwan 1945 1951 - Oct 1 0:00 0 S Rule Taiwan 1952 only - Mar 1 0:00 1:00 D Rule Taiwan 1952 1954 - Nov 1 0:00 0 S Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D Rule Taiwan 1955 1961 - Oct 1 0:00 0 S Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D Rule Taiwan 1974 1975 - Oct 1 0:00 0 S Rule Taiwan 1980 only - Jun 30 0:00 1:00 D Rule Taiwan 1980 only - Sep 30 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Taipei 8:06:00 - LMT 1896 # or Taibei or T'ai-pei 8:00 Taiwan C%sT 1992 8:00 - CST # Macau (Macao, Aomen) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Macau 1961 1962 - Mar Sun>=16 3:30 1:00 S Rule Macau 1961 1964 - Nov Sun>=1 3:30 0 - Rule Macau 1963 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1964 only - Mar Sun>=16 3:30 1:00 S Rule Macau 1965 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1965 only - Oct 31 0:00 0 - Rule Macau 1966 1971 - Apr Sun>=16 3:30 1:00 S Rule Macau 1966 1971 - Oct Sun>=16 3:30 0 - Rule Macau 1972 1974 - Apr Sun>=15 0:00 1:00 S Rule Macau 1972 1973 - Oct Sun>=15 0:00 0 - Rule Macau 1974 1977 - Oct Sun>=15 3:30 0 - Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 - CST This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.

1 0

Difftime code
by Clive D.W. Feather Aug. 5, 2004

Aug. 5, 2004

[Hmm, I don't think this got out properly yesterday.] Okay, I've looked at the problem a bit. I also note that there's some portability problems in the code in 2004b. In particular, if time_t is a signed integer type then the calculation of delta can involve undefined behaviour; you cannot assume twos-complement unflagged wrap-around in signed integer types. time_t has to be either an integer type or a real-floating type [C99 allows it to be a complex-floating type, but POSIX doesn't]. We can easily distinguish these cases: if ((time_t) 0.2 != (time_t) 0.4) // It's a real-floating type else // It's an integer type If it's real-floating, then: return (long double) time1 - time0; is as accurate as you can get: the subtraction is done in long double (the conversion to this is lossless) and the rounding to double happens at the end. If it's integer, it's a bit harder; I'll assume for simplicity that time1>time0. if (time0 >= 0 || time1 < 0) return time1 - time0; In this case, the subtraction won't overflow; if the result is representable, it'll be rounded at the end. In the remaining case, a simple subtraction could overflow and you're in trouble. So we need to find the "top type": * on a C99 implementation, this is uintmax_t; * on a C89 implementation, this is unsigned long; * on non-conforming implementations you have a problem, but the most likely case is unsigned long or unsigned long long. #if __STDC__ == 1 && __STDC_VERSION__ >= 199901L #define HAVE_UINTMAX_T #endif #ifdef HAVE_UINTMAX_T #include <stdint.h> typedef uintmax_t top_type; #else #ifdef HAVE_LONG_LONG typedef unsigned long long top_type; #else typedef unsigned long top_type; #endif #endif This code works correctly on C89 and C99 conforming implementations, but you may have to tune it for others. If we now cast the two values to (top_type) and subtract, we get a value which is either: time1 - time0 OR time1 - time0 - BASIS (BASIS is 2 to the power N, where N is the number of bits in top_type). The latter case can only happen if top_type has the same number of *value* bits as time_t and so has the same maximum value, *and* the subtraction overflows. time_t s4 = time1 / 4 - time0 / 4; top_type dt = (top_type) time1 - (top_type) time0; top_type t4 = dt / 4; At this point, t4 is either approximately equal to s4, in which case dt is correct, or the right answer is dt + BASIS, in which case t4 is approximately s4 - BASIS / 4. So: if (t4 > s4 - (top_type)-1 / 8) return dt; So now we can't stay in integer types to calculate the entire value. Rather, we need to do dt + BASIS in long double. top_type halfBASIS = (top_type)-1 / 2 + 1; return 2.0L * halfBASIS + dt; I'm not in a position to do a full analysis, but let me note that we're adding two positive values, so you don't have the issues you do with subtraction and the addition can only lose 1ulp of precision. Furthermore, on a binary machine the first operand can be represented exactly. So, putting that all together and making some cosmetic changes and minor optimisations: #if __STDC__ == 1 // and the implementation isn't lying about this #if __STDC_VERSION >= 199901L #include <stdint.h> typedef uintmax_t top_type; #else typedef unsigned long top_type; #endif typedef long double long_double; #else // You'll have to fill this in using your own portability guidelines typedef ???? top_type; // The widest range unsigned integer type typedef ???? long_double; // The widest range floating-point type #endif double difftime (const time_t time1, const time_t time0) { time_t s4; top_type dt; if ((time_t) 0.2 != (time_t) 0.4) return (long_double) time1 - time0; if (time1 < time0) return -difftime (time0, time1); if (time0 >= 0 || time1 < 0) return time1 - time0; s4 = (time1 >> 2) - time0 / 4; // time0 < 0, so >> is a bad idea dt = (top_type) time1 - (top_type) time0; if ((dt >> 2) > s4 - ((top_type)-1 >> 3)) return dt; return (long_double) 2 * ~((top_type)-1 >> 1) + dt; } If you don't like this approach, then I have one other suggestion. Rather than using sizeof as a placeholder for the precision of various types, you can use the values FLT_RADIX and LDBL_MANT_DIG (in <float.h>) to calculate the largest integer that can be represented exactly in long double: static long double maxLDint = 0.0; if (maxLDint < 100.0) { int i; for (i = 0; i < LDBL_MANT_DIG; i++) maxLDint = maxLDint * FLT_RADIX + (FLT_RADIX - 1); } But you still need to address some of your other bugs in your code. -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

1 0

Re: asctime.c
by Olson, Arthur David (NIH/NCI) Aug. 5, 2004

Aug. 5, 2004

Thanks to all for feedback on asctime.c. The version below uses %02.2d for universality, uses %4ld for years to avoid problems if a year isn't four digits long, and avoids the use of snprintf (which isn't available on some systems). There are comments on all these changes. Is it soup yet? --ado /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson (arthur_david_olson(a)nih.gov) */ #ifndef lint #ifndef NOID static char elsieid[] = "@(#)asctime.c 7.15"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ #include "private.h" #include "tzfile.h" #define STANDARD_BUFFER_SIZE 26 /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * asctime_r(timeptr, buf) register const struct tm * timeptr; char * buf; { static const char wday_name[][3] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; static const char mon_name[][3] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; register const char * wn; register const char * mn; /* ** Big enough for something such as ** ??? ???-2147483648 -2147483648:-2147483648:-2147483648 -2147483648\n ** (two three-character abbreviations, five strings denoting integers, ** three explicit spaces, two explicit colons, a newline, ** and a trailing ASCII nul). */ char result[2 * 3 + 5 * INT_STRLEN_MAXIMUM(int) + 3 + 2 + 1 + 1]; if (timeptr->tm_wday < 0 || timeptr->tm_wday >= DAYSPERWEEK) wn = "???"; else wn = wday_name[timeptr->tm_wday]; if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) mn = "???"; else mn = mon_name[timeptr->tm_mon]; /* ** The format used in the (2004) standard is ** "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n" ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ** All years associated with 32-bit time_t values are exactly ** four digits long; some years associated with 64-bit time_t ** values are not four digits long so we throw in the 4 below. */ /* ** We avoid using snprintf since it's not available on all systems. */ (void) sprintf(result, "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %4ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, timeptr->tm_year + (long) TM_YEAR_BASE); if (strlen(result) >= STANDARD_BUFFER_SIZE) { errno = EOVERFLOW; return NULL; } else { (void) strcpy(buf, result); return buf; } } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * asctime(timeptr) register const struct tm * timeptr; { static char result[STANDARD_BUFFER_SIZE]; return asctime_r(timeptr, result); }

5 22

Proposed asctime-related changes
by Olson, Arthur David (NIH/NCI) Aug. 5, 2004

Aug. 5, 2004

Below are proposed asctime-related changes to the time zone package; in particular, documentation and Makefile changes are now included. I hope to roll out new versions of tzcode and tzdata incorporating these changes in about a week; I'll then tackle other suggested changes that have been circulated on the time zone mailing list of late. --ado diff -c -r old/Makefile new/Makefile *** old/Makefile Mon Jul 19 14:33:20 2004 --- new/Makefile Thu Aug 5 10:59:53 2004 *************** *** 1,4 **** ! # @(#)Makefile 7.92 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.94 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 103,108 **** --- 103,110 ---- # -DLOCALE_HOME=\"path\" if locales are in "path", not "/usr/lib/locale" # -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?) # -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h" + # -DSTRICTLY_STANDARD_ASCTIME=1 if you want a strictly standard (and arguably + # broken) version of asctime (see asctime.c for details) # -DTZDEFRULESTRING=\",date/time,date/time\" to default to the specified # DST transitions if the time zone files cannot be accessed # -DTZ_DOMAIN=\"foo\" to use "foo" for gettext domain name; default is "tz" *************** *** 244,251 **** TZCSRCS= zic.c localtime.c asctime.c scheck.c ialloc.c TZCOBJS= zic.o localtime.o asctime.o scheck.o ialloc.o ! TZDSRCS= zdump.c localtime.c asctime.c ialloc.c ! TZDOBJS= zdump.o localtime.o asctime.o ialloc.o DATESRCS= date.c localtime.c logwtmp.c strftime.c asctime.c DATEOBJS= date.o localtime.o logwtmp.o strftime.o asctime.o LIBSRCS= localtime.c asctime.c difftime.c --- 246,253 ---- TZCSRCS= zic.c localtime.c asctime.c scheck.c ialloc.c TZCOBJS= zic.o localtime.o asctime.o scheck.o ialloc.o ! TZDSRCS= zdump.c localtime.c ialloc.c ! TZDOBJS= zdump.o localtime.o ialloc.o DATESRCS= date.c localtime.c logwtmp.c strftime.c asctime.c DATEOBJS= date.o localtime.o logwtmp.o strftime.o asctime.o LIBSRCS= localtime.c asctime.c difftime.c diff -c -r old/asctime.c new/asctime.c *** old/asctime.c Mon Jul 19 14:33:22 2004 --- new/asctime.c Thu Aug 5 10:21:02 2004 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 7.9"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 7.19"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 14,23 **** #include "private.h" #include "tzfile.h" /* ! ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, Second Edition, 1996-07-12. */ char * asctime_r(timeptr, buf) register const struct tm * timeptr; --- 14,65 ---- #include "private.h" #include "tzfile.h" + #if STRICTLY_STANDARD_ASCTIME + #define ASCTIME_FMT "%.3s %.3s%3d %.2d:%.2d:%.2d %ld\n" + #define ASCTIME_FMT_B ASCTIME_FMT + #else /* !STRICTLY_STANDARD_ASCTIME */ /* ! ** Some systems only handle "%.2d"; others only handle "%02d"; ! ** "%02.2d" makes (most) everybody happy. ! ** At least some versions of gcc warn about the %02.2d; ignore the warning. */ + /* + ** All years associated with 32-bit time_t values are exactly four digits long; + ** some years associated with 64-bit time_t values are not. + ** Vintage programs are coded for years that are always four digits long + ** and may assume that the newline always lands in the same place. + ** For years that are less than four digits, we pad the output with + ** spaces before the newline to get the newline in the traditional place. + */ + #define ASCTIME_FMT "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %-4ld\n" + /* + ** For years that are more than four digits we put extra spaces before the year + ** so that code trying to overwrite the newline won't end up overwriting + ** a digit within a year and truncating the year (operating on the assumption + ** that no output is better than wrong output). + */ + #define ASCTIME_FMT_B "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %ld\n" + #endif /* !STRICTLY_STANDARD_ASCTIME */ + #define STD_ASCTIME_BUF_SIZE 26 + /* + ** Big enough for something such as + ** ??? ???-2147483648 -2147483648:-2147483648:-2147483648 -2147483648\n + ** (two three-character abbreviations, five strings denoting integers, + ** seven explicit spaces, two explicit colons, a newline, + ** and a trailing ASCII nul). + ** The values above are for systems where an int is 32 bits and are provided + ** as an example; the define below calculates the maximum for the system at + ** hand. + */ + #define MAX_ASCTIME_BUF_SIZE (2*3+5*INT_STRLEN_MAXIMUM(int)+7+2+1+1) + + static char buf_asctime[MAX_ASCTIME_BUF_SIZE]; + + /* + ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. + */ + char * asctime_r(timeptr, buf) register const struct tm * timeptr; *************** *** 32,37 **** --- 74,81 ---- }; register const char * wn; register const char * mn; + long year; + char result[MAX_ASCTIME_BUF_SIZE]; if (timeptr->tm_wday < 0 || timeptr->tm_wday >= DAYSPERWEEK) wn = "???"; *************** *** 39,59 **** if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) mn = "???"; else mn = mon_name[timeptr->tm_mon]; /* ! ** The X3J11-suggested format is ! ** "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %d\n" ! ** Since the .2 in 02.2d is ignored, we drop it. */ ! (void) sprintf(buf, "%.3s %.3s%3d %02d:%02d:%02d %d\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, ! TM_YEAR_BASE + timeptr->tm_year); ! return buf; } /* ! ** A la X3J11, with core dump avoidance. */ char * --- 83,113 ---- if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) mn = "???"; else mn = mon_name[timeptr->tm_mon]; + year = timeptr->tm_year + (long) TM_YEAR_BASE; /* ! ** We avoid using snprintf since it's not available on all systems. */ ! (void) sprintf(result, ! ((year >= -999 && year <= 9999) ? ASCTIME_FMT : ASCTIME_FMT_B), wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, ! year); ! if (strlen(result) < STD_ASCTIME_BUF_SIZE || buf == buf_asctime) { ! (void) strcpy(buf, result); ! return buf; ! } else { ! #ifdef EOVERFLOW ! errno = EOVERFLOW; ! #else /* !defined EOVERFLOW */ ! errno = EINVAL; ! #endif /* !defined EOVERFLOW */ ! return NULL; ! } } /* ! ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * *************** *** 60,74 **** asctime(timeptr) register const struct tm * timeptr; { ! /* ! ** Big enough for something such as ! ** ??? ???-2147483648 -2147483648:-2147483648:-2147483648 -2147483648\n ! ** (two three-character abbreviations, five strings denoting integers, ! ** three explicit spaces, two explicit colons, a newline, ! ** and a trailing ASCII nul). ! */ ! static char result[3 * 2 + 5 * INT_STRLEN_MAXIMUM(int) + ! 3 + 2 + 1 + 1]; ! ! return asctime_r(timeptr, result); } --- 114,118 ---- asctime(timeptr) register const struct tm * timeptr; { ! return asctime_r(timeptr, buf_asctime); } diff -c -r old/newctime.3 new/newctime.3 *** old/newctime.3 Mon Jul 19 14:33:21 2004 --- new/newctime.3 Thu Aug 5 11:49:18 2004 *************** *** 39,53 **** representing the time in seconds since 00:00:00 UTC, 1970-01-01, and returns a pointer to a ! 26-character string ! of the form .br .ce .eo Thu Nov 24 18:22:48 1986\n\0 .ec .br ! All the fields have constant width. .PP .IR Localtime\^ and --- 39,59 ---- representing the time in seconds since 00:00:00 UTC, 1970-01-01, and returns a pointer to a ! string of the form .br .ce .eo Thu Nov 24 18:22:48 1986\n\0 + .br + .ce .ec + For years longer than four characters, the string is of the form .br ! .ce ! .eo ! Thu Nov 24 18:22:48 81986\n\0 ! .ec ! .br .PP .IR Localtime\^ and *************** *** 72,81 **** .PP .I Asctime\^ converts a time value contained in a ! ``tm'' structure to a 26-character string, as shown in the above example, ! and returns a pointer ! to the string. .PP .I Mktime\^ converts the broken-down time, --- 78,86 ---- .PP .I Asctime\^ converts a time value contained in a ! ``tm'' structure to a string, as shown in the above example, ! and returns a pointer to the string. .PP .I Mktime\^ converts the broken-down time, *************** *** 211,214 **** Avoid using out-of-range values with .I mktime when setting up lunch with promptness sticklers in Riyadh. ! .\" @(#)newctime.3 7.14 --- 216,219 ---- Avoid using out-of-range values with .I mktime when setting up lunch with promptness sticklers in Riyadh. ! .\" @(#)newctime.3 7.15 diff -c -r old/newctime.3.txt new/newctime.3.txt *** old/newctime.3.txt Mon Jul 19 14:33:34 2004 --- new/newctime.3.txt Thu Aug 5 11:49:27 2004 *************** *** 36,45 **** DESCRIPTION Ctime converts a long integer, pointed to by clock, representing the time in seconds since 00:00:00 UTC, 1970- ! 01-01, and returns a pointer to a 26-character string of the ! form Thu Nov 24 18:22:48 1986\n\0 ! All the fields have constant width. Localtime and gmtime return pointers to ``tm'' structures, described below. Localtime corrects for the time zone and --- 36,45 ---- DESCRIPTION Ctime converts a long integer, pointed to by clock, representing the time in seconds since 00:00:00 UTC, 1970- ! 01-01, and returns a pointer to a string of the form Thu Nov 24 18:22:48 1986\n\0 ! For years longer than four characters, the string is of the form ! Thu Nov 24 18:22:48 81986\n\0 Localtime and gmtime return pointers to ``tm'' structures, described below. Localtime corrects for the time zone and *************** *** 52,59 **** Gmtime converts to Coordinated Universal Time. Asctime converts a time value contained in a ``tm'' ! structure to a 26-character string, as shown in the above ! example, and returns a pointer to the string. Mktime converts the broken-down time, expressed as local time, in the structure pointed to by tm into a calendar time --- 52,59 ---- Gmtime converts to Coordinated Universal Time. Asctime converts a time value contained in a ``tm'' ! structure to a string, as shown in the above example, and ! returns a pointer to the string. Mktime converts the broken-down time, expressed as local time, in the structure pointed to by tm into a calendar time diff -c -r old/zdump.c new/zdump.c *** old/zdump.c Mon Jul 19 14:33:22 2004 --- new/zdump.c Thu Aug 5 10:48:37 2004 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.33"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.34"; /* ** This code has been made independent of the rest of the time *************** *** 129,134 **** --- 129,135 ---- static size_t longest; static char * progname; static void show P((char * zone, time_t t, int v)); + static void dumptime P((const struct tm * tmp)); int main(argc, argv) *************** *** 343,352 **** struct tm * tmp; (void) printf("%-*s ", (int) longest, zone); ! if (v) ! (void) printf("%.24s UTC = ", asctime(gmtime(&t))); tmp = localtime(&t); ! (void) printf("%.24s", asctime(tmp)); if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); if (v) { --- 344,355 ---- struct tm * tmp; (void) printf("%-*s ", (int) longest, zone); ! if (v) { ! dumptime(gmtime(&t)); ! (void) printf(" UTC = "); ! } tmp = localtime(&t); ! dumptime(tmp); if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); if (v) { *************** *** 369,372 **** --- 372,404 ---- return &nada; result = tzname[tmp->tm_isdst]; return (result == NULL) ? &nada : result; + } + + static void + dumptime(timeptr) + register const struct tm * timeptr; + { + static const char wday_name[][3] = { + "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" + }; + static const char mon_name[][3] = { + "Jan", "Feb", "Mar", "Apr", "May", "Jun", + "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" + }; + register const char * wn; + register const char * mn; + + if (timeptr->tm_wday < 0 || + timeptr->tm_wday >= sizeof wday_name / sizeof wday_name[0]) + wn = "???"; + else wn = wday_name[timeptr->tm_wday]; + if (timeptr->tm_mon < 0 || + timeptr->tm_mon >= sizeof mon_name / sizeof mon_name[0]) + mn = "???"; + else mn = mon_name[timeptr->tm_mon]; + (void) printf("%.3s %.3s%3d %.2d:%.2d:%.2d %ld", + wn, mn, + timeptr->tm_mday, timeptr->tm_hour, + timeptr->tm_min, timeptr->tm_sec, + timeptr->tm_year + (long) TM_YEAR_BASE); }

2 1

RE: asctime.c
by Olson, Arthur David (NIH/NCI) Aug. 5, 2004

Aug. 5, 2004

Is using "%-4ld" to print the year a happy medium? --ado

8 23

Looking for non-TZ-dependent localtime()
by Michael Lindner Aug. 4, 2004

Aug. 4, 2004

I have a multithreaded server that has a thread per client, and needs to talk to clients in their local timezone. All the "normal" UNIX time functions rely on "TZ" for timezone information, so even though they're nominally "thread-safe" they don't support my application, since TZ is global across threads. Is there a localtime()-like implementation out there that can do what I need, or do I have to write one? And if not and I have to write one, what code base is the "correct" one to start from (e.g. Linux, tzcode2003e.tar.gz from elsi.nci.nih.gov, etc.)? Thanks, -- Michael Lindner

4 4

RE: asctime.c
by Martinez, Andres Aug. 3, 2004

Aug. 3, 2004

I need to unsubscribe to this email... But there is no message at the bottom with instructions... Can you help? -----Original Message----- From: Paul Eggert [mailto:eggert@penguin.cs.ucla.edu] On Behalf Of Paul Eggert Sent: Tuesday, August 03, 2004 10:02 AM To: Clive D.W. Feather Cc: tz(a)lecserver.nci.nih.gov Subject: Re: asctime.c "Clive D.W. Feather" <clive(a)demon.net> writes: > Can you give me an example? Sure. Here's an example taken from the code I happened to be looking at 30 seconds before reading your email. It's taken from GNU coreutils "od.c". I've paraphrased the code slightly to simplify it. enum size_spec { NO_SIZE, CHAR, SHORT, INT, LONG } ; enum size_spec integral_type_size[sizeof (long) + 1]; for (i = 0; i <= MAX_INTEGRAL_TYPE_SIZE; i++) integral_type_size[i] = NO_SIZE; integral_type_size[sizeof (char)] = CHAR; integral_type_size[sizeof (short)] = SHORT; integral_type_size[sizeof (int)] = INT; integral_type_size[sizeof (long)] = LONG; This code has undefined behavior if, for example, sizeof (long) is 4 and sizeof (int) is 8. The code in difftime.c is a bit more subtle than this, and now that I look at it more carefully it can't strictly be justified in terms of either C89 or C99 (though it is true on all platforms I know about). However, I'd say that the general principle that sizeof(int) <= sizeof(long) is hardwired into a lot of real-world code. If there aren't any real implementations with sizeof(long) < sizeof(int), then this is only of academic interest. Still, it's strange that this longstanding requirement would get removed from the standard. After all, it's a natural assumption.

1 0