- tz - lists.iana.org

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

zic, zdump, date patch needed for proper handling of locales
by Paul Eggert July 29, 2004

July 29, 2004

Andreas Schwab <schwab(a)suse.de> writes: >> 2000-10-23 Jakub Jelinek <jakub(a)redhat.com> >> >> * timezone/zdump.c (main): setlocale LC_CTYPE as well as LC_MESSAGES. >> * timezone/zic.c (main): Likewise. > > It would be nice if that would be included upstream. OK, here's a patch suitable for inclusion in the tz sources, which I'm sending to the tz list. The problem here is that one can't reliably set parts of a locale without setting them consistently; otherwise the behavior is undefined, and on some hosts things go very badly. The problem here is with LC_CTYPE, but it could occur in other locale components. The simplest fix is to use LC_ALL, which sets everything consistently. =================================================================== RCS file: RCS/date.c,v retrieving revision 2001.4.0.1 retrieving revision 2001.4.0.2 diff -pu -r2001.4.0.1 -r2001.4.0.2 --- date.c 2004/06/15 05:53:49 2001.4.0.1 +++ date.c 2004/07/29 22:50:01 2001.4.0.2 @@ -117,13 +117,12 @@ char * argv[]; INITIALIZE(adjust); INITIALIZE(t); #if HAVE_GETTEXT - 0 - (void) setlocale(LC_MESSAGES, ""); + (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined(TEXTDOMAINDIR) */ (void) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT - 0 */ - (void) setlocale(LC_TIME, ""); (void) time(&now); format = value = NULL; while ((ch = getopt(argc, argv, "ucnd:t:a:")) != EOF && ch != -1) { =================================================================== RCS file: RCS/zdump.c,v retrieving revision 2004.2.0.1 retrieving revision 2004.2.0.2 diff -pu -r2004.2.0.1 -r2004.2.0.2 --- zdump.c 2004/07/20 23:27:39 2004.2.0.1 +++ zdump.c 2004/07/29 22:50:01 2004.2.0.2 @@ -184,7 +184,7 @@ char * argv[]; struct tm * newtm; #if HAVE_GETTEXT - 0 - (void) setlocale(LC_MESSAGES, ""); + (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined(TEXTDOMAINDIR) */ =================================================================== RCS file: RCS/zic.c,v retrieving revision 2004.1 retrieving revision 2004.1.0.1 diff -pu -r2004.1 -r2004.1.0.1 --- zic.c 2004/03/02 15:54:30 2004.1 +++ zic.c 2004/07/29 22:50:01 2004.1.0.1 @@ -467,7 +467,7 @@ char * argv[]; (void) umask(umask(S_IWGRP | S_IWOTH) | (S_IWGRP | S_IWOTH)); #endif /* defined unix */ #if HAVE_GETTEXT - 0 - (void) setlocale(LC_MESSAGES, ""); + (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined TEXTDOMAINDIR */

1 0

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

July 29, 2004

Here's my latest effort at asctime.c. In this version, asctime itself never returns NULL which I trust makes folks happy. Given kre's points about avoiding breaking existing code, the format of what asctime returns is not always standard conforming which I trust makes some folks unhappy. Feedback welcome. --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.16"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ #include "private.h" #include "tzfile.h" #if STRICTLY_STANDARD_ASCTIME #define ASCTIME_FMT "%.3s %.3s%3d %.2d:%.2d:%.2d %d\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. */ /* ** 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 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; 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; long year; char result[MAX_ASCTIME_BUF_SIZE]; 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]; 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 { errno = EOVERFLOW; return NULL; } } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * asctime(timeptr) register const struct tm * timeptr; { return asctime_r(timeptr, buf_asctime); }

2 1

Request to mailing list Lesstif rejected
by lesstif-admin＠lesstif.org July 29, 2004

July 29, 2004

Your request to the Lesstif mailing list Posting of your message titled "Deliver Mail (lesstif(a)hungry.com)" has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: "Non-members are not allowed to post messages to this list." Any questions or comments should be directed to the list administrator at: lesstif-admin(a)lesstif.org

1 0

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

July 28, 2004

snprintf's behavior is to return the number of characters that would have been generated had the output buffer not been limited. That being true, I think the asctime.c below does what Paul intended. Does anyone see problems with using this in the next bundle? --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.13"; #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; register int result; 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" ** Use "%02d", as it is a bit more portable than "%.2d". */ result = snprintf(buf, STANDARD_BUFFER_SIZE, "%.3s %.3s%3d %02d:%02d:%02d %ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, timeptr->tm_year + (long) TM_YEAR_BASE); if (result < 0 || result >= STANDARD_BUFFER_SIZE) { errno = EOVERFLOW; return NULL; } return buf; } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition, ** with core dump avoidance. */ char * asctime(timeptr) register const struct tm * timeptr; { static char result[STANDARD_BUFFER_SIZE]; return asctime_r(timeptr, result); }

5 9

FW: asctime.c
by Olson, Arthur David (NIH/NCI) July 28, 2004

July 28, 2004

-----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Tuesday, July 27, 2004 5:24 AM To: Paul Eggert Cc: Olson, Arthur David (NIH/NCI); Tz Subject: Re: asctime.c Date: Tue, 27 Jul 2004 00:37:12 -0700 From: Paul Eggert <eggert(a)CS.UCLA.EDU> Message-ID: <87zn5lew9j.fsf(a)penguin.cs.ucla.edu> None of my messages (these days) ever make it to the list - I suspect some absurd anti-spam "protection" killing all of my mail. But never mind that for now. | /* | ** The format used in the (2004) standard is | ** "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n" | ** Use "%02d", as it is a bit more portable than "%.2d". | */ The most postable format is %02.2d - that works on every printf I've ever seen that has any method to make a 2 column zero-filled numeric field. Nothing else works on everything (the %02d version is original Research unix/BSD variants, the %.2d version is original Sys III type stuff I think - for a 2 character field, it probably doesn't matter, except possibly for the value 0 (where a system that likes %.2d might produce just " 0" if given %02d - the "0" in the format (SysIII variant) requires a leading 0 in the result, or something like that, so for 1, you should get 01, but for 0 ...) | result = snprintf(buf, STANDARD_BUFFER_SIZE, | "%.3s %.3s%3d %02d:%02d:%02d %ld\n", Please make that %4ld - it never mattered before, because the year was always between 1900 and 21xx, so there were always 4 digits anyway. But now if you're going to allow for year 10, etc, that 4 digit field needs to be forced to be 4 characters wide. It really is supposed to be that, not just "the rest of the line". The \n should be in buf[25] and absolutely nowhere else (for correct historical compatibility). That is, doing buf[25] = '\0'; to the result of asctime() is the "time honoured" way of printing the result without the trailing \n (that or using "%.24s" which amounts to the same thing). kre

2 1

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

July 28, 2004

> But the C standard says that sometimes fewer bytes of output must be generated (in particular, if the year is in the range -99 through 999)... What I find at http://www.opengroup.org/onlinepubs/009695399/functions/asctime.html (you may have to register via http://www.unix-systems.org/version3/iso_std.html to access the above, and your URLage may vary) is this text: The asctime() function shall convert the broken-down time in the structure pointed to by timeptr into a string in the form: Sun Sep 16 01:03:52 1973\n\0 using the equivalent of the following algorithm: char *asctime(const struct tm *timeptr) { static char wday_name[7][3] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; static char mon_name[12][3] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; static char result[26]; sprintf(result, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n", wday_name[timeptr->tm_wday], mon_name[timeptr->tm_mon], timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, 1900 + timeptr->tm_year); return result; } That last "%d" in the sprintf would indeed produce less than four digits of year output in some cases. Of course we might also take the above as meaning that it's mandatory for asctime to overflow a buffer (and potentially dump core) for other cases (take tm_year >= 10000, please). Sidebar: I believe kre is proposing padding with spaces rather than zeroes. --ado

3 2

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

July 27, 2004

From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Tuesday, July 27, 2004 11:49 AM To: Olson, Arthur David (NIH/NCI) Cc: Tz Subject: Re: asctime.c ... | /* | ** 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]; > That buffer is big enough for that string, but are we sure that string > is the longest that can ever happen? The year is after all printed > using %ld - so there must at least be the potential for that one to be a long, which might be -9223372036854775808. > Beyond that, C doesn't actually promise that "int" is limited to 32 > bits does it? Given that, the 2147483648 numbers are just speculation. We're using "INT_STRLEN_MAXIMUM(int)" to figure out how long the output for an integer value might be. The macro figures out the length based on "sizeof int", so even if an int is more than 32 bits things will come out right. While we're using a %ld format to print out out the year, what we're printing is the sum of an int (tm_year) and 1900 (TM_YEAR_BASE), so we know the result is int sized. --ado

1 0

Where to download the database
by Craig Orput July 26, 2004

July 26, 2004

Your site is very confusing to me. Where do I download the actual time zone database, in text version? Regards Craig Orput Vice President - Logistics Engineering OIA SCM 17230 NE Sacramento Street Portland, OR 97230 Office 503.872.8470 craig.orput(a)oiascm.com http://www.oiascm.com/

1 0

Re: another attempt to change the clocks in the UK
by Peter Ilieve July 26, 2004

July 26, 2004

Back on 9 June when I mentioned Nigel Beard's Lighter Evenings Bill I wrote: > I haven't found the text of the Bill itself yet. It will probably > turn up on the Parliament website next week. It was finally published on Wednesday. PDF and HTML versions can be found at <http://www.publications.parliament.uk/pa/cm200304/cmbills/115/2004115.htm>. It is a short Bill of only four sections. It changes the time for general purposes to one hour in advance of GMT. It amends the Scotland Act 1998 to make time zones and summer time arrangements a devolved rather than a reserved matter, which will allow the Scottish parliament to keep Scotland on GMT if they so wish. It makes some amendments to the Summer Time Act 1972 which I presume are to allow Northern Ireland, the Channel Islands and the Isle of Man to do their own thing as well (I don't have a copy of the 1972 Act handy to check this). By pure coincidence a relative of mine works as a researcher for Nigel Beard and has spent the last couple of months working on this. What seems to have happened is that Nigel became convinced by the safety arguments for change and decided to do something about it. At this stage he didn't know about John Butterfill's `Extra Daylight' Bill or Lord Archer's similar measure that he introduced during his doomed campaign for London mayoral candidate. Finding all this out was left to his researcher. She produced a briefing which Nigel's ten minute rule speech was based on. In turn, she then passed the specification for the proposed change on to the parliamentary draughtsmen, who add the legalese so it will pass muster as a Bill. The next stage is the Bill's second reading, which is set for 15 October. This is where the first vote on the Bill will take place. If the vote is lost that's it. If it passes the Bill goes to the next, committee, stage. If you look at the Public Bill List on the Parliament website (<http://www.publications.parliament.uk/pa/cm/cmpblist/cmpblist.htm>) you will see that there are literally dozens of Bills down for second reading on 15 October. The second reading is supposed to be the first detailed consideration of a Bill. You can judge for yourselves what sort of scrutiny each of these dozens of Bills will get. My view remains that this Bill has almost no chance of becoming law. Ten minute rule Bills come even further down the pecking order than private members' Bills like John Butterfill's one, and his failed. Bills like this only really stand a chance if they have government support, as the government can give them parliamentary time. I have spoken to someone at the DTI (the department now dealing with time related stuff) and they told me that the government is not in favour of this change, as it would be disruptive to business, transport and tourism, particularly if the UK no longer used a single time zone. Peter Ilieve peter(a)aldie.co.uk

2 1

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

July 23, 2004

Code in "asctime" such as... { long y; y = timeptr->tm_year + (long) TM_YEAR_BASE; if (y >= -999 && y <= 9999) (void) sprintf(buf, "%.3s %.3s%3d %02d:%02d:%02d %ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, y); else (void) sprintf(buf, "%.3s %.3s%3d %ld\n", wn, mn, timeptr->tm_mday, y); } ...never returns NULL and never (when applied to a "struct tm" derived from a 64-bit time_t) overflows a 26-character buffer passed to asctime. It does lose time-of-day information in the distant past and distant future. --ado

3 2

Asctime.c
by Olson, Arthur David (NIH/NCI) July 22, 2004

July 22, 2004

At the end of this message is a revised version of asctime.c. There are a couple of standard-related matters. 1. The POSIX standard calls for a struct tm that includes an "int tm_year" member. If time_t is 64 bits and int is 32 bits, tm_year won't be able to represent all the years associated with time_t values. Should the standard address this issue? 2. The standard reads... The asctime_r() function shall convert the broken-down time in the structure pointed to by tm into a string (of the same form as that returned by asctime()) that is placed in the user-supplied buffer pointed to by buf (which shall contain at least 26 bytes) and then return buf. ...but a 26-byte buffer won't be adequate if a five-digit (or more) year is involved. Should the standard address this issue? Should "asctime_r" assume that the fed-in buffer is at most 26 bytes and avoid overflowing it? --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.11"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ #include "private.h" #include "tzfile.h" /* ** 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; 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" ** Use "%02d", as it is a bit more portable than "%.2d". ** Drop each .3 since they're superfluous given how we set wn and mn. */ (void) sprintf(buf, "%s %s%3d %02d:%02d:%02d %ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, timeptr->tm_year + (long) TM_YEAR_BASE); return buf; } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition, ** with core dump avoidance. */ char * 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); }

3 3

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

July 20, 2004

Chris Richards is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Chris Richards [mailto:cj_richards@hotmail.com] Sent: Friday, July 09, 2004 9:53 AM To: tz(a)lecserver.nci.nih.gov Subject: Definition of time_t changed from signed to unsigned... Hello, I am in the process of upgrading the kernel version on a platform that I work on. I noticed that the time_t definition has been changed in the newer version of the OS. It used to be a simple "long". But it is now an "unsigned long". Basically it changed from a signed to an unsigned definition. The problem is that the timezone subsystem seems to expect time_t to be signed. There are a number of functions that only work if time_t is signed. E.g. function localsub() in file localtime.c. My question is: am I just using an obsolete version of the timezone source or should I just change the time_t typedef in the OS? I quickly scanned the latest source of localtime.c and did not see any changes regarding to how time_t is declared. Thanks in advance, Chris. _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page - FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/

6 8

Tzcode2004b.tar.gz and tzdata2004b.tar.gz
by Olson, Arthur David (NIH/NCI) July 19, 2004

July 19, 2004

The files... ftp://elsie.nci.nih.gov/pub/tzcode2004b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2004b.tar.gz ...are now available. These contain the data changes circulated last week on the time zone mailing list by Paul Eggert--most importantly, they include updates for Argentina. I wanted to get these out quickly since they effect present-day operations down south. I'm holding off (briefly, I hope) on incorporating code changes until I can do a more thorough review than I have time for just now. --ado

1 0