- tz - lists.iana.org

Some bugs in timezone reported to the Debian project
by Fernando Alegre Jan. 18, 1996

Jan. 18, 1996

I maintain the timezone utilities for the Debian project. In case you don't know, the Debian project is the result of a volunteer effort to create a high-quality non-commercial Linux distribution which will be supported by the Free Software Foundation. As part of this project we have set up a bug tracking system. Users post bug reports and the Debian maintainers try to fix them or forward them to the developer of a given package. There are some bugs related to the timezone utilities which haven't been fixed for some time. I would like them to be considered for the next release of these packages. Here is the list of outstanding bugs: 1) Reported by Herbert Xu <herbert(a)greathan.apana.org.au> PRC abandoned daylight saving in 1992 or 1993 but currently the files do not reflect this change. 2) Reported by Raul Miller <rdm(a)tad.micro.umn.edu> zdump output from all of the files in the US directory gives GMT times. 3) Reported by Raul Miller <rdm(a)tad.micro.umn.edu> there appears to be a complete duplicate set of files under zoneinfo/right 4) Reported by Raul Miller <rdm(a)tad.micro.umn.edu> either zdump is broken or the zoneinfo files are broken -- they depend on the file name rather than file contents to determine their time zone. This makes "localtime" rather useless, because it conceals the file name. [My interpretation is: zdump needs an option for dumping files] Our bug tracking system needs that a separate e-mail message is sent for each bug, so that all messages regarding the same bug can be automatically archived together. In order for this to function, it is necessary for me to send you a separate message for each bug with a Subject: line reading "Re: Bug#0000". Therefore you will receive 4 more messages in the near future. I am asking you to kindly keep the Subject: line of each message untouched, as well as the Cc: field. If you need more details please feel free to contact me. Thank you for your attention. Regards, Fernando Alegre alegre(a)mars.superlink.net

1 0

tzcode96c.tar.gz
by ado Jan. 16, 1996

Jan. 16, 1996

tzcode96c.tar.gz is now available for anonymous ftp from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory: -rw-r--r-- 1 ado 73301 Jan 16 16:58 tzcode96c.tar.gz It incorporates the leap-year streamlining and binary-search changes noted on the mailing list, as well as the fix to newctime.3. --ado

1 0

A patch to newctime.3
by J.T. Conklin Jan. 15, 1996

Jan. 15, 1996

The enclosed patch removes text that says that localtime calls tzset if it hasn't been called before. Localtime (as well as asctime, ctime, mktime and strftime) now always call tzset. There should probably be text added that documents the real behavior. --jtc Index: newctime.3 =================================================================== RCS file: /home/cvsroot/tz/tzcode/newctime.3,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 newctime.3 *** newctime.3 1996/01/15 21:48:02 1.1.1.1 --- newctime.3 1996/01/15 22:00:31 *************** *** 56,68 **** .I Localtime\^ corrects for the time zone and any time zone adjustments (such as Daylight Saving Time in the U.S.A.). - Before doing so, - .I localtime\^ - calls - .I tzset\^ - (if - .I tzset\^ - has not been called in the current process). After filling in the ``tm'' structure, .I localtime sets the --- 56,61 ----

1 0

tzcode96b.tar.gz and ISO8601
by fred＠genesis.demon.co.uk Jan. 15, 1996

Jan. 15, 1996

Hello! I've recently been 'dabbling' in dates and in particular ISO8601 week numbers so I was interested in tzcode96b.tar.gz, in particular the strftime.c file. First however I'll just point out something minor in tzfile.h which is: #define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0) This is not the best way to test for a leap year since if the year is not divisible by 4 we know it is not divisible by 400 (but it tests for this anyway). The more usual form is: #define isleap(y) (((y) % 4) == 0 && (((y) % 100) != 0 || ((y) % 400) == 0)) My main interest is in the following extract from the code for the 'V' (amongst others) conversion specifier: #ifdef XPG4_1994_04_09 if (w == 52 && t->tm_mon == TM_JANUARY) w = 53; #endif /* defined XPG4_1994_04_09 */ Is it true that XPG4 has a slightly different definition of week number than ISO8601? What this appears to be saying is that if week 52 crosses into the new year the days in January become week 53 (but if week 53 crosses the year boundary it stays as week 53). The following is the function I wrote to calculate ISO8601 week numbers. I've added an 'XPG4' option in what I believe to be an equivalent way (this means that points 2 and 6 of the 'rules' aren't quite correct for XPG4). Since I'm submitting something similar for inclusion in the free 'Snippets' library any thoughts would be welcome. /****************************************************************************** * weeknum_ISO8601 January 1996 L.Kirby * * Released to the Public Domain * * Calculates the week number of a day in the year based on the ISO8601 week * numbering scheme. The arguments are: * * t - a pointer to a struct tm in which the following members must be set and * normalised to the standard ranges specified (as standard library * functions gmtime, localtime and mktime should do): * * tm_wday - The day of the week of the day in question: * 0-Sunday -> 6-Saturday * * tm_yday - The day of the year of the day in question: 0 -> 365 * January 1st is day 0. * * tm_year - The year since 1900. * * firstdow - This defines the day of the week on which a week starts: * 0-Sunday -> 6-Saturday. For normal ISO8601 weeks that start on * a Monday this should be 1. * ****************************************************************************** * * The week number is a value between 1 and 53 inclusive defined according to * the following rules: * * 1. The Gregorian calendar is assumed. * * 2. There are always 7 consecutive days with the same week number. * * 3. January 4th is defined to be in week 1. Equivalently week 1 is the * first week of a year which has at least 4 days in that year. * * 4. firstdow defines the day of the week which starts a new week i.e. has * a different week number from the previous day. * * 5. Week numbers increase in sequence from week 1 until the week that is * defined to be week 1 of the following year. * * It follows that: * * 6. Up to January 3rd may be in either week 1 of the current year or in * weeks 52 or 53 of the previous year. * * 7. 29th December onwards may be in either weeks 52 or 53 of the current * year or week 1 of the following year. * ****************************************************************************** */ #include <time.h> #define isleap(year) (!((year) % 4) && (((year) % 100) || !((year) % 400))) int weeknum_ISO8601(const struct tm *t, int firstdow) { const int tmp1 = firstdow - t->tm_wday; const int tmp2 = t->tm_yday + ((tmp1 > 0) ? 3 : 10) + tmp1; const int fourthdaynum = tmp2 % 7; int week = tmp2 / 7; if (week == 0) { #ifdef XPG4_1994_04_09 week = 53; #else const int year = t->tm_year + (1900 % 400) - 1; week = (fourthdaynum + isleap(year) >= 6) ? 53 : 52; #endif } else if (week == 53) { const int year = t->tm_year + (1900 % 400); if (fourthdaynum > isleap(year)) week = 1; } return week; } -- ----------------------------------------- Lawrence Kirby | fred(a)genesis.demon.co.uk Wilts, England | 70734.126(a)compuserve.com -----------------------------------------

1 0

minor tz tuneups and portability fix
by Paul Eggert Jan. 15, 1996

Jan. 15, 1996

Here are some proposed very minor code tuneups for the tz code. While accumulating these I noticed a portability bug in localtime.c; the expression `(t < 0) ? 0 : ((time_t) 1 << bits)' yields undefined results if time_t is unsigned, since `bits' is the number of bits in a time_t in that case. The patch below fixes this bug as part of the tuneups. =================================================================== RCS file: RCS/tzfile.h,v retrieving revision 1995.3 retrieving revision 1995.3.1.1 diff -c -r1995.3 -r1995.3.1.1 *** tzfile.h 1995/03/11 17:55:58 1995.3 --- tzfile.h 1996/01/15 06:22:59 1995.3.1.1 *************** *** 153,159 **** ** that will probably do. */ ! #define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0) #ifndef USG --- 153,159 ---- ** that will probably do. */ ! #define isleap(y) (((y) % 4) == 0 && (((y) % 100) != 0 || ((y) % 400) == 0)) #ifndef USG =================================================================== RCS file: RCS/difftime.c,v retrieving revision 1994.8 retrieving revision 1994.8.1.1 diff -c -r1994.8 -r1994.8.1.1 *** difftime.c 1994/12/09 04:33:32 1994.8 --- difftime.c 1996/01/15 06:22:59 1994.8.1.1 *************** *** 43,51 **** /* ** Repair delta overflow. */ ! hibit = 1; ! while ((hibit <<= 1) > 0) ! continue; /* ** The following expression rounds twice, which means ** the result may not be the closest to the true answer. --- 43,49 ---- /* ** 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. *************** *** 65,74 **** ** This problem occurs only with very large differences. ** It's too painful to fix this portably. ** We are not alone in this problem; ! ** many 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. */ return delta - 2 * (long_double) hibit; } --- 63,72 ---- ** 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; } =================================================================== RCS file: RCS/localtime.c,v retrieving revision 1995.7 retrieving revision 1995.7.1.1 diff -c -r1995.7 -r1995.7.1.1 *** localtime.c 1995/10/30 15:32:46 1995.7 --- localtime.c 1996/01/15 06:22:59 1995.7.1.1 *************** *** 1163,1175 **** tmp->tm_hour = (int) (rem / SECSPERHOUR); rem = rem % SECSPERHOUR; tmp->tm_min = (int) (rem / SECSPERMIN); ! tmp->tm_sec = (int) (rem % SECSPERMIN); ! if (hit) ! /* ! ** A positive leap second requires a special ! ** representation. This uses "... ??:59:60" et seq. ! */ ! tmp->tm_sec += hit; tmp->tm_wday = (int) ((EPOCH_WDAY + days) % DAYSPERWEEK); if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; --- 1163,1173 ---- tmp->tm_hour = (int) (rem / SECSPERHOUR); rem = rem % SECSPERHOUR; tmp->tm_min = (int) (rem / SECSPERMIN); ! /* ! ** A positive leap second requires a special ! ** representation. This uses "... ??:59:60" et seq. ! */ ! tmp->tm_sec = (int) (rem % SECSPERMIN) + hit; tmp->tm_wday = (int) ((EPOCH_WDAY + days) % DAYSPERWEEK); if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; *************** *** 1344,1358 **** /* ** Calculate the number of magnitude bits in a time_t ** (this works regardless of whether time_t is ! ** signed or unsigned, though lint complains if unsigned). */ ! for (bits = 0, t = 1; t > 0; ++bits, t <<= 1) ! continue; /* ** If time_t is signed, then 0 is the median value, ! ** if time_t is unsigned, then 1 << bits is median. */ ! t = (t < 0) ? 0 : ((time_t) 1 << bits); for ( ; ; ) { (*funcp)(&t, offset, &mytm); dir = tmcomp(&mytm, &yourtm); --- 1342,1355 ---- /* ** Calculate the number of magnitude bits in a time_t ** (this works regardless of whether time_t is ! ** signed or unsigned). */ ! bits = TYPE_BIT(time_t) - TYPE_SIGNED(time_t); /* ** If time_t is signed, then 0 is the median value, ! ** if time_t is unsigned, then 1 << (bits - 1) is median. */ ! t = TYPE_SIGNED(time_t) ? 0 : ((time_t) 1 << (TYPE_BIT(time_t) - 1)); for ( ; ; ) { (*funcp)(&t, offset, &mytm); dir = tmcomp(&mytm, &yourtm);

2 1

tzcode96b.tar.gz
by ado Jan. 11, 1996

Jan. 11, 1996

The file tzcode96b.tar.gz is available for anonymous ftp from the ~ftp/pub directory of elsie.nci.nih.gov (165.112.73.1): -rw-r--r-- 1 ado 73347 Jan 10 20:43 tzcode96b.tar.gz It contains fixes and enhancements from Paul Eggert, including code that emulates the behavior of recent versions of the SunOS "date" command. --ado

1 0

tzcode96a.tar.gz and tzdata96a.tar.gz
by ado Jan. 6, 1996

Jan. 6, 1996

These files are now available by anonymous ftp from the ~ftp/pub directory on elsie.nci.nih.gov (165.112.73.1): -rw-r--r-- 1 ado 73078 Jan 6 09:08 tzcode96a.tar.gz -rw-r--r-- 1 ado 72790 Jan 6 09:08 tzdata96a.tar.gz The "data" file includes the Israel updates recently circulated on the mailing list; the "code" file contains fixes to strftime.c for correct ISO 8601 week number generation, plus support for two new formats ('G' and 'g') to give ISO 8601 year numbers (which are not necessarily the same as calendar year numbers). --ado

1 0

changes for Israel's daylight savings rules in 1996-1998
by Paul Eggert Jan. 3, 1996

Jan. 3, 1996

Ephraim Silverberg reports that on January 1 the government of Israel announced changes for Israel's DST transitions for the years 1996-1998. The first change is the autumn 1996 transition. The revised rules are reflected by the patch below, which is relative to the latest published tz data. =================================================================== RCS file: RCS/asia,v retrieving revision 1995.13 retrieving revision 1995.13.1.1 diff -c -r1995.13 -r1995.13.1.1 *** asia 1995/12/21 17:18:23 1995.13 --- asia 1996/01/03 02:23:13 1995.13.1.1 *************** *** 438,444 **** #Rule Zion 1991 only - Mar 10 0:00 1:00 D #Rule Zion 1991 only - Sep 1 0:00 0 S ! # From Ephraim Silverberg (September 20, 1995): # # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. --- 438,444 ---- #Rule Zion 1991 only - Mar 10 0:00 1:00 D #Rule Zion 1991 only - Sep 1 0:00 0 S ! # From Ephraim Silverberg (1996-01-02): # # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. *************** *** 451,457 **** # time annually. Ever since 1993, the change to daylight savings time has # been from midnight Thursday night to 1 a.m. Friday morning and the change # back to standard time on Saturday night from midnight daylight savings time ! # to 11 p.m. standard time. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D --- 451,459 ---- # time annually. Ever since 1993, the change to daylight savings time has # been from midnight Thursday night to 1 a.m. Friday morning and the change # back to standard time on Saturday night from midnight daylight savings time ! # to 11 p.m. standard time. 1996 is an exception to this rule where the ! # change back to standard time takes place on Sunday night instead of Saturday ! # night to avoid conflicts with the Jewish New Year. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1989 only - Apr 30 0:00 1:00 D *************** *** 481,499 **** # # ftp://ftp.huji.ac.il/pub/misc/timezones/announcements/1996-1998.ps.gz # ! # Emptor Caveat: The fall of 1996 is an election year (the change to/from ! # daylight savings time affects the earliest possible time for morning prayers ! # making it is a sensitive issue among the religious sector of the electorate) ! # so political considerations may cause the outgoing government to make the ! # change back to standard time earlier in the fall of 1996 and the incoming ! # government may nullify the 1997/1998 times altogether depending on the ! # coalition formed after the elections. Life isn't boring here in Israel. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 1998 - Mar Fri>=14 0:00 1:00 D ! Rule Zion 1996 only - Sep 22 0:00 0:00 S ! Rule Zion 1997 only - Nov 2 0:00 0:00 S ! Rule Zion 1998 only - Oct 25 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 --- 483,502 ---- # # ftp://ftp.huji.ac.il/pub/misc/timezones/announcements/1996-1998.ps.gz # ! # Emptor Caveat: The dates for the years 1996-1998 were originally announced ! # on August 31, 1995, by the previous Minister of Interior. The new Minister ! # of Interior changed the dates on January 1, 1996, to take into account the ! # desires of certain portions of Israeli society (the next election is in the ! # Fall of 1996). After this (1996) year's Daylight Savings Time is over, the ! # new minister has announced that a study will be conducted as to the wishes of ! # the populace regarding the length of Daylight Savings Time and the Interior ! # Committee will meet to review the results of the study and make any necessary ! # changes to the 1997-1998 dates. Never a dull moment in the State of Israel. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 1998 - Mar Fri>=14 0:00 1:00 D ! Rule Zion 1996 only - Sep 16 0:00 0:00 S ! Rule Zion 1997 1998 - Oct Sun>=14 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tel_Aviv 2:19:04 - LMT 1880

1 0

errors in ISO week number [forwarded with permission of all concerned]
by ado Jan. 2, 1996

Jan. 2, 1996

Attached find excerpts from correspondence on ISO 8601 week numbers (forwarded with permission of all concerned) and a proposed set of changes to strftime.c to cope with the issues raised. An extension to strftime to return the ISO 8601 year (which may be different from the year represented by tm_year) is also needed; does anyone know of an existing implementation that handles ISO years (and, if so, the specification for the formatting letter used and the value returned)? --ado

1 0

Re: errors in ISO week number
by arnold＠skeeve.atl.ga.us Jan. 1, 1996

Jan. 1, 1996

Hello Hume, > Don Libes <libes(a)cme.nist.gov> has pointed me to you directly... > i had mentioned that the ISO week of Jan 1 was never 52 > with the code he'd had, although just over 1 time in 7 > it should be. he got new code from you, which seems > to have the right week for Jan 1 but not always Dec 1 - > it should sometimes be in week 1 of "next" year... > > e.g. 1973 Dec 31 should be in week 1 of 1974. I think I disagree rather strongly with this. Dec 31 should always be in the last week of the year. This just makes sense. The question is whether it's week 52 or week 53. Unless the ISO standard actually *says* that it's in week 1 of the following year, I don't want to change my code... (And if it does say that, then In My Not So Humble Opinion it's silly.) > i've taken a very different technique for calculating ISO week numbers > in some code of my own. (i was comparing it to expect's timestamp, which > uses your code, and the calendar stuff in emacs 19.30) although it's > only designed to work for 100 years (i assume a leap year every four years, > so after 2100 Feb 28 i'll be a day off, etc), it's so much simpler you may > want to adapt/adopt it... > > x = ut/(60*60*24) number of days = unix time / length of day > x = x + 3 adjust to the previous monday > ISOday = 1 + x%7 weekday > x = x/7 number of weeks > y = (28*x+2)/1461 number of years > x = x - (1461*y+25)/28 number of weeks into year > ISOyear = 1970+y > ISOweek = 1+x > > (the divisions should be C integer divisions) > > the best way to fix it for the rest of the gregorian cycle is probably > to change the 2 and the 25. note that whatever they're changed to, must > sum to 27. (if you're interested in this method, i'll try to complete > it for you if you'd prefer...) > -- > Hume Smith <hclsmith(a)isisnet.com> NetBSD r00lz :) > > > Real Americans don't carry cash. Their police may steal it.d Ado and Tor, comments? ... ===============================================================================

3 3