- tz - lists.iana.org

Is Mexico starting DST back up?
by Alan.Perry＠Eng.Sun.COM Jan. 31, 1996

Jan. 31, 1996

I just got a query from our Mexico subsidiary stating that Mexico is resuming DST in April (after many years of not doing DST). This is not reflected in the current tzdata from elsie. Does anyone have any details about this? alan

1 0

Bangalore not in the same time zone as Calcutta?
by guy＠netapp.com Jan. 30, 1996

Jan. 30, 1996

This is a message that showed up in "info.sun-managers"; the only time zone I could find for India in the "tzdata96b" file was # India # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Calcutta 5:53:28 - LMT 1880 5:53 - CMT 1941 Oct # Calcutta Mean Time 6:30 - BMT 1942 May 15 5:30 - IST 1942 Sep 5:30 1:00 IST 1945 Oct 15 5:30 - IST which is 5 1/2 hours from GMT, not 5 hours from GMT.... From: jerome(a)india.ti.com (Jerome Alphonse) Newsgroups: info.sun-managers Subject: date problems between Solaris and SunOS Date: 27 Jan 1996 20:06:01 -0600 Organization: UTexas Mail-to-News Gateway Message-ID: <199601270204.HAA02126(a)supernova.india.ti.com> Hello Gurus Our timezone is GMT+5. We have setup our machines in this timezone So in SunOS machines , if I give date command ,the output is Sat Jan 27 06:45:57 GMT+0500 1996 Which seems to be okay. In Solaris machines, if I give date command, the output is (though we have set it up as GMT+5,during installation) Sat Jan 27 06:45:01 GMT 1996 Becoz' of which we are not able to run certain Solaris applications which look into SUNOS or HP-UX machines for licensing as license gives error saying that time gap is more than it could handle (probably those wretched 5 hours). Becoz of this time stamp of the files created across NFS( between SUNOS and Solaris), is also crazy In Solaris machines -rw-rw-r-- 1 aravind 0 Jan 26 20:47 123 -rw-rw-r-- 1 aravind 0 Jan 26 20:47 234 In Solaris machines ,same files(across NFS) -rw-rw-r-- 1 aravind 0 Jan 27 06:47 123 -rw-rw-r-- 1 aravind 0 Jan 27 06:47 234 And also due to this time zone problem , I suspect there are some NFS mount problems which I posted in this forum a day or two before. Regards Jerome \\|// \\|// @@@@ ($$) (@@) (!!) ----o00--()--00o------o00--()--o00--------o00-()-00o------ Jerome Alphonse Email: jerome(a)india.ti.com Systems Engineer Phone: 011-91-80-2264235/9 Texas Instruments Fax : 011-91-80-2267024 Bangalore 560052 India URL : http://www.india.ti.com/~jerome/ ===========================================================

1 0

tzdata96b.tar.gz
by ado Jan. 27, 1996

Jan. 27, 1996

The file tzdata96b.tar.gz is now available from elsie.nci.nih.gov (165.112.73.1): -rw-r--r-- 1 ado 73021 Jan 27 15:44 tzdata96b.tar.gz This includes the Kiribati change. --ado

1 0

proposed updates for Kiribati and Israel
by Paul Eggert Jan. 22, 1996

Jan. 22, 1996

Time zones made front-page news in today's _Wall Street Journal_, which reports that various countries in the Pacific are jockeying to be the first to welcome the 21st century, since this is rumored to be good for the tourist trade. So far, Kiribati has been the only one to officially change its clocks (see below) but we might see other changes in the future. The most extreme case is a threat by Cuba to move its clocks ahead 24 hours! Also, the stated rule for picking locations: # Use the most populous among locations in a country's time zone, # e.g. prefer `Shanghai' to `Beijing'. Among locations with # similar populations, pick the best-known location, # e.g. prefer `Rome' to `Milan'. suggests that Asia/Jerusalem is a better name choice than Asia/Tel_Aviv. Which location has the higher population depends on how you're counting (city limits? or metropolitan area?) and in the case of similar populations, Jerusalem should be chosen since it's better-known. Asia/Tel_Aviv should be retained for backward compatibility, of course. Here is a proposed patch. =================================================================== RCS file: RCS/australasia,v retrieving revision 1995.13 retrieving revision 1995.13.1.1 diff -c -r1995.13 -r1995.13.1.1 *** australasia 1995/12/21 17:18:27 1995.13 --- australasia 1996/01/22 21:06:45 1995.13.1.1 *************** *** 208,222 **** # uninhabited # Kiribati # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - NZST Zone Pacific/Enderbury -11:24:20 - LMT 1901 -12:00 - KJT 1979 Oct ! -11:00 - SST Zone Pacific/Kiritimati -10:29:20 - LMT 1901 -10:40 - LIT 1979 Oct # Line Is Time ! -10:00 - THT # N Mariana Is # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 208,228 ---- # uninhabited # Kiribati + # From Paul Eggert (1996-01-22): + # Today's _Wall Street Journal_ (page 1) reports that Kiribati + # ``declared it the same day throught the country as of Jan. 1, 1995'' + # as part of the competition to be first into the 21st century. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - NZST Zone Pacific/Enderbury -11:24:20 - LMT 1901 -12:00 - KJT 1979 Oct ! -11:00 - SST 1995 ! 13:00 - TGT Zone Pacific/Kiritimati -10:29:20 - LMT 1901 -10:40 - LIT 1979 Oct # Line Is Time ! -10:00 - THT 1995 ! 14:00 - KRT # N Mariana Is # Zone NAME GMTOFF RULES FORMAT [UNTIL] *************** *** 362,367 **** --- 368,377 ---- -10:00 - THT # Tonga + # From Paul Eggert (1996-01-22): + # Today's _Wall Street Journal_ (page 1) reports that ``Tonga has been plotting + # to sneak ahead of [New Zealanders] by introducing daylight-saving time.'' + # But since Kiribati has moved the Date Line it's not clear what Tonga will do. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Tongatapu 12:19:20 - LMT 1901 12:20 - TMT 1968 Oct *************** *** 403,409 **** # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (August 18, 1994): # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), # San Diego: ACS Publications, Inc. (1991). --- 413,419 ---- # go ahead and edit the file (and please send any changes to # tz(a)elsie.nci.nih.gov for general use in the future). ! # From Paul Eggert <eggert(a)twinsun.com> (1996-01-22); # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks, The International Atlas (3rd edition), # San Diego: ACS Publications, Inc. (1991). *************** *** 436,441 **** --- 446,452 ---- # 12:00 NZST NZDT New Zealand # 12:45 CHST CHDT Chatham* # 13:00 TGT Tongatapu* + # 14:00 KRT Kiritimati* # -12:00 KJT Kwajalein (no longer used)* # -11:00 SST Samoa # -10:40 LIT Line Is (no longer used)* =================================================================== RCS file: RCS/asia,v retrieving revision 1996.1 retrieving revision 1996.1.1.1 diff -c -r1996.1 -r1996.1.1.1 *** asia 1996/01/06 14:08:15 1996.1 --- asia 1996/01/22 21:06:45 1996.1.1.1 *************** *** 499,505 **** 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 2:21 - JMT 1918 2:00 Zion I%sT --- 499,505 ---- Rule Zion 1997 1998 - Oct Sun>=14 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Asia/Jerusalem 2:20:56 - LMT 1880 2:21 - JMT 1918 2:00 Zion I%sT =================================================================== RCS file: RCS/backward,v retrieving revision 1995.13 retrieving revision 1995.13.1.1 diff -c -r1995.13 -r1995.13.1.1 *** backward 1995/12/21 17:18:38 1995.13 --- backward 1996/01/22 21:06:45 1995.13.1.1 *************** *** 7,12 **** --- 7,13 ---- Link America/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/St_Thomas America/Virgin + Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI *************** *** 45,51 **** Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran ! Link Asia/Tel_Aviv Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein --- 46,52 ---- Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran ! Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein

1 0

UK timezone news --- Summary: don't panic
by peter＠aldie.co.uk Jan. 21, 1996

Jan. 21, 1996

UK timezone matters came to a head on Friday 18 January when John Butterfill MP failed to get a second reading in the House of Commons for his British Time (Extra Daylight) Bill. This means nothing will change. This story starts back in 1989 when the Home Office, the department responsible for these things, produced a consultation document on Summer Time. Officially the Government were neutral, but it was widely reported that they wanted to move the UK into the central European timezone, GMT+1 in winter and GMT+2 in summer. Back then the EC (as it was then called) hadn't agreed on a common Summer Time end date so this proposed change was bound up with European harmonisation. There was a wide divergence of opinion in the responses to the document and the Government couldn't decide what to do. I am not aware of any statement being published. The Home Office, if you ask them, say the whole matter `is under consant review'. A friend of mine elsewhere in the Civil Service translates this as `we haven't a clue what to do about this and we wish it would go away'. In the intervening years the EC Commission agreed the seventh Directive on summertime arrangements which finally introduced a common end date. As this date was basically the UK end date, with all the other countries changing from the end of September to the end of October, this removed one of the objections in the UK for European harminisation: that it would lead to darker evenings in October. As the EC Commission has said several times that it is solely interested in harmonising dates and has no interest in what timezone countries are in, the responsibility for any change would now fall squarely on the UK Government and could not be blamed on Europe. In January 1995 a member of the House of Lords (the upper house of our Parliament), Viscount Mountgarret, introduced his Central European Time Bill. In the debate he complained bitterly about the lack of decision since 1989 and said the Government had broken several specific committments to him that things would be done. His Bill proposed that England, Wales and Northern Ireland, but not Scotland, move to CET. This moves the timezone boundary from the English Channel up to the Scottish border. The Scots, because of being in the far north and west of the UK, have been the most vociferous opponents of any change. His Bill was given a second reading, nobody put their names down to speak in the next, committee, stage, so as far as I understand Lords procedure it passed. It had no chance of becoming law however as nobody introduced it in the House of Commons. I think that Viscount Mountgarret introduced the Bill at least partly to put the Government on the spot and force some sort of decision. In that he failed. The action now moves to the House of Commons. Every year when the new session of Parliament starts there is a ballot among MPs for places on the list for introducing Private Members Bills. Only the first few MPs in the list have any hope of getting their Bill (which they might not even have thought of when they enter the ballot) passed into law, and then usually only with help in the form of debating time from the Government. Last year John Butterfill came top of the list, and announced he would introduce a British Time (Extra Daylight) Bill to move the whole of the UK into the CET zone. I think he offered the Scots the option of opting out if they wanted to but nobody really took this seriously. This did put the Government on the spot as they would have to decide whether to give it time. I asked the Home Office last week and all they would say was: `the Government's position was that it was not a party political matter and it would be decided by Parliament on a free vote'. It was widely reported though that they wouldn't give it time, the Scottish Office ministers had won the right to vote against it and all other ministers had been instructed to abstain or have some other engagement so they wouldn't be in the House at all. In the event none of this was really necessary. Last Friday, after a good humoured debate, the Bill fell on a technicality. One hundred MPs were required (I don't know why, some arcane rule) to vote in favour of a motion to close the debate, so the Bill's second reading vote could take place. Only 93 voted in favour and the Bill was lost. The Government escapes one again without having to make any decision. So, nothing changes as a result of all this, but the backers of the Bill, who call themselves the Daylight Extra Campaign, have already said they will be back. There will have to be an election in the UK before the end of April next year and if the current opinion polls are to be believed the Conservative Party are heading for a drubbing of possibly Canadian proportions. The Daylight Extra folk are already talking of bringing the proposal back, possibly as a 5 year experiment, after a change of Government. One of the most depressing things about all this is that many people have been taken in by John Butterfill's `(Extra Daylight)' and somehow think that politicians can conjure the stuff out of thin air. Peter Ilieve peter(a)aldie.co.uk

2 1

Re: Bug#1229
by Alan.Perry＠Eng.Sun.COM Jan. 18, 1996

Jan. 18, 1996

> From guy(a)netapp.com Wed Jan 17 21:58 PST 1996 > > 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. > > The latest version of the time zone data files appear to reflect this: > > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Shang 1928 only - Jan 1 0:00 0 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 > > although earlier versions didn't, I think (the files in SunOS 5.4 > doesn't, for example, and they're probably based on an earlier version). SunOS 5.4 (Solaris 2.4) zoneinfo files are taken from tzdata94d. There should be a patch available that will update this to tzdata95c (I think). We still need to update our zic to compile some of the latest zoneinfo files (like europe) as well as fix zdump, which we (I) :-( broke in 2.4. alan

1 0

Re: Bug#1229
by Fernando Alegre Jan. 18, 1996

Jan. 18, 1996

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 1

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

updated time zone files
by ado Dec. 21, 1995

Dec. 21, 1995

The files in the ~ftp/pub directory of elsie.nci.nih.gov (165.112.73.1) have been updated: -rw-r--r-- 1 ado 70806 Dec 21 12:46 tzcode95i.tar.gz -rw-r--r-- 1 ado 72634 Dec 21 12:46 tzdata95m.tar.gz The latest revisions from Paul Eggert are included, the usno1995 file has been updated, and a new file ("WWW") covering useful URLs has been added. --ado

1 0

Has Sudan been updated?
by Alan.Perry＠Eng.Sun.COM Dec. 20, 1995

Dec. 20, 1995

mross(a)antigone.com wrote: >Sudan no longer observes any form of daylight savings time change. I just pulled down the latest tzdata files from elsie and this change does not appear to be reflected there. What's the deal? alan

3 2

new tz files
by ado Dec. 19, 1995

Dec. 19, 1995

Now available on elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory: -rw-r--r-- 1 ado 69655 Dec 19 18:15 tzcode95h.tar.gz -rw-r--r-- 1 ado 70026 Dec 19 18:15 tzdata95l.tar.gz No major changes from the last versions: a simplification of a macro definition, a change to data for Sudan, and (for last minute shoppers) notes in the "Music" file on the CD "Old Man Time." --ado

1 0

Re: Has Sudan been updated?
by ado Dec. 19, 1995

Dec. 19, 1995

> mross(a)antigone.com wrote: > >Sudan no longer observes any form of daylight savings time change. > > I just pulled down the latest tzdata files from elsie and this change > does not appear to be reflected there. What's the deal? I'd been hoping to get word on when Sudan stopped using DST. Having failed, I've put a note in the file and punted. You should almost immediately receive a note to the TZ list announcing the new stuff. Thanks for the reminder! --ado

1 0

question regarding setting latest zone names in tzname [forwarded with permission]
by ado Nov. 20, 1995

Nov. 20, 1995

Has anybody instrumented the time zone code to determine where the sinks are? Is the area questioned below one of them? --ado > ...We have started to look at performance in this software. > I have a question that I was hoping you could answer about one piece of code > in particular in the routine settzname. It is the code filling in the > time zone name in tzname. The code fragment is: > > /* > ** And to get the latest zone names into tzname. . . > */ > for (i = 0; i < sp->timecnt; ++i) { > register const struct ttinfo * const ttisp = > > &sp->ttis[sp->types[i]]; > > tzname[ttisp->tt_isdst] = > (char *) &sp->chars[ttisp->tt_abbrind]; > } > > I am not sure why this code is looping so many times to fill in > tzname. tzname only has two fields, one for daylight savings time, > one for standard savings time, but the fields get filled in > over and over. I would really appreciate any information you have > explaining this. > > thanks in advance, > > Sandra Whitman > DEC C RTL

1 0

tz data for Sudan
by Michael Ross Nov. 16, 1995

Nov. 16, 1995

Sudan no longer observes any form of daylight time change. I verified this today by telephone with the Sudan Mission to the United Nations: 212-573-6033 Cheers, --- Michael Ross Antigone Press, San Francisco, California e-mail: mross(a)antigone.com FAX: +1 415 550 1957 --- > > # Sudan > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Sudan 1931 only - Feb 8 0:00 0 - > Rule Sudan 1970 only - May 1 0:00 1:00 " DST" > Rule Sudan 1970 max - Oct 15 0:00 0 - > Rule Sudan 1971 only - Apr 30 0:00 1:00 " DST" > Rule Sudan 1972 max - Apr lastSun 0:00 1:00 " DST" > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Khartoum 2:10:08 - LMT 1931 > 2:00 Sudan EET%s

2 1

tz data for Burma
by Michael Ross Nov. 15, 1995

Nov. 15, 1995

Hello, You might want to use the offical new name: Myanmar... # Burma # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Rangoon 6:24:40 - LMT 1880 6:25 - RMT 1920 6:30 - BMT 1942 May 9:00 - JST 1945 May 3 6:30 - BMT --- Michael Ross Antigone Press, San Francisco, California e-mail: mross(a)antigone.com FAX: +1 415 550 1957 ---

1 0

questions and comments on http://tycho.usno.navy.mil/tzones.html
by Paul Eggert Nov. 12, 1995

Nov. 12, 1995

Thanks for putting the USNO unofficial time zone info on the Web; it has helped me compose proposed patches for the public domain time zone history database at <ftp://elsie.nci.nih.gov/pub/tzdata95k.tar.gz>. After comparing the USNO data to other sources, I have some questions and comments. I'd appreciate any information you can send me to clear up the questions, especially pointers to other sources. The tzdata history database relies heavily on Thomas G. Shanks, The International Atlas (3rd edition), San Diego: ACS Publications (1991), a source that is now 4 years old, so some of the discrepancies noted below are undoubtedly because the time zones or daylight savings rules have changed recently. But I thought I'd tell you about the discrepancies just in case. <http://tycho.usno.navy.mil/tzones.html> (1995-11-11) says: Antarctica: -2 hours (Local summer -3 hours) Which part of Antarctica is that? I have the vague impression that different research stations in Antarctica use different local times. (The South Pole is the most interesting case, of course.) Armenia: +4 hours (Local summer +5 hours) Shanks has Armenia switching to +3 (+4 summer) in 1991. Perhaps they've switched back? Argentina western prov: -4 hours Shanks says Argentina has always had just one time zone. Azerbajian: +3 hours Shanks has Baku at +3 (+4 summer). Perhaps they've stopped using daylight savings time? Brazil Acre: -4 hours (Local summer -5 hours) Brazil Atlantic Islands: -1 hours (Local summer -2 hours) Brazil East: -3 hours (Local summer -1 hours) These must be typos. Here are proposed fixes. Brazil Acre: -5 hours (Local summer -4 hours) Brazil Atlantic Islands: -2 hours (Local summer -1 hours) Brazil East: -3 hours (Local summer -2 hours) Chatham Island: +12.75 hours (Local summer +13.75 hours) Do you have a source for when the transition to and from summer time takes place? Cocos (Keeling) Islands: ( hours (Local summer ) hours) This is a typo. The 1989 USNO listing has Cocos at +6.5 hours. Cook Islands: -10 hours Shanks has Cook at -9.5 during summer. The 1989 USNO listing had two entries for Cook, one at -10, the other at -10 (-9.5 summer) like Shanks. Equitorial Guinea: +1 hours This should be `Equatorial Guinea'. French Polynesia: -10 hours French Polynesia covers several time zones; e.g. I think the Marquesas and Gambier are part of French Polynesia, and they are at -9.5 and -9, respectively. Georgia: +4 hours Shanks says Georgia has summer time, but this may have changed with the rules change late last year (see _The Economist_, 1994-11-19, page 60). Is there a better source for this? Greenland Scoresbysun: -1 hours (Local summer 0 hours) This should be `Scoresbysund'. Guinea Bissau: - hours (Local summer 0 hours) This should be `0 hours', with no summer time. Kazakhstan: +6 hours (Local summer +7 hours) Shanks says Alma-Ata switched to +5 (+6 summer) in 1991. Perhaps they've switched back? Kiribati: +12 hours The country of Kiribati covers several time zones. Perhaps you could change `Kiribati' to `Tarawa'. Kwajalein: -12 hours In comp.risks 14.87 <http://catless.ncl.ac.uk/Risks/14.87.html#subj2> (1993-08-26), Peter Neumann writes that Kwajalein changed to +12 hours on 1993-08-20. Libya: +2 hours Shanks has Libya at +1 (summer +2). Mexico Baja Calif Norte: -8 hours (Local summer -7 hours) Shanks has Ensenada, southern Baja, at -8 all year. Mongolia: +8 hours Shanks says Mongolia has 3 time zones: +7 (+8 summer), +8 (+9 summer), and +9 (+10 summer). Namibia: +1 hours (Local summer +2 hours) Nicaragua: -6 hours (Local summer -5 hours) Shanks has Namibia at +2 all year, and Nicaragua at -6 all year. If these have changed recently, do you know when it changed, and what the transition times are? Russian Federation zone two: +4 hours (Local summer +5 hours) This must be a typo; it should be `+3 hours (Local summer +4 hours)'. Scotland: 0 hours Shanks and other sources have Scotland at +1 in summer. Tajikistan: +6 hours Shanks has Tajikistan at +5 (+6 summer). Perhaps they've switched? Tunisia: +1 hours Shanks has Tunisia at +2 in summer. Perhaps they've stopped using DST? Turkmenistan: +5 hours Shanks has Turkmenistan at +6 during summer. Perhaps they've stopped using DST? Ukraine: +2 hours (Local summer +3 hours) Ukraine has multiple time zones. _The Economist_ (1994-05-28, page 45) reports that Crimea switched to +3 (summer +4) last year. Uzbekistan: +5 hours Shanks has Tashkent at +5 (+6 summer). Perhaps they've stopped using daylight savings time?

1 0