February 1996 - tz - lists.iana.org

Timezone change for Mexico: the Presidential Decree
by Alan.Perry＠Eng.Sun.COM Feb. 15, 1996

Feb. 15, 1996

A guy from our Mexico subsidiary finally found the Presidential Decree outlining the timezone changes in Mexico. ------------- Begin Forwarded Message ------------- I finally got my hands on the Official Presidential Decree that sets up the rules for the DST changes. The rules are: 1. The country is divided in 3 timezones: - Baja California Norte (the Mexico/BajaNorte TZ) - Baja California Sur, Nayarit, Sinaloa and Sonora (the Mexico/BajaSur TZ) - The rest of the country (the Mexico/General TZ) 2. From the first Sunday in April at 2:00 AM to the last Sunday in October at 2:00 AM, the times in each zone are as follows: BajaNorte: GMT+7 BajaSur: GMT+6 General: GMT+5 3. The rest of the year, the times are as follows: BajaNorte: GMT+8 BajaSur: GMT+7 General: GMT+6 The Decree was published in Mexico's Official Newspaper on January 4th. -------------- End Forwarded Message --------------

1 0

Re: mktime() failure vs 31-DEC-1969 23:59:59 GMT
by ado Feb. 14, 1996

Feb. 14, 1996

> > The standards for mktime() define a return value of > > (time_t)-1 as indicating that the time specified cannot be > > represented. However, a return value of -1 is also a valid time_t > > corresponding to 31-DEC-1969 23:59:59 GMT. How do we distinguish > > between the two? > > Call localtime() on the seemingly-in-error mktime() result, and compare > the relevant portions of the structs tm. A match implies a non-error. Since there's normalization going on in mktime, the tm that comes back from localtime may not match the one that went in to mktime even if -1 is being returned as a legitimate time_t rather than an error indication. Another possibility is to save away the original tm structure; if mktime returns -1, bump the tm_sec value by 1, call mktime again, and see if it returns zero. --ado

2 1

Re: mktime() failure vs 31-DEC-1969 23:59:59 GMT
by Bradley White Feb. 14, 1996

Feb. 14, 1996

> The standards for mktime() define a return value of > (time_t)-1 as indicating that the time specified cannot be > represented. However, a return value of -1 is also a valid time_t > corresponding to 31-DEC-1969 23:59:59 GMT. How do we distinguish > between the two? Call localtime() on the seemingly-in-error mktime() result, and compare the relevant portions of the structs tm. A match implies a non-error.

2 1

mktime() failure vs 31-DEC-1969 23:59:59 GMT
by tomp＠zk3.dec.com Feb. 14, 1996

Feb. 14, 1996

This has probably been discussed before, but perhaps someone can bring me up to speed. The standards for mktime() define a return value of (time_t)-1 as indicating that the time specified cannot be represented. However, a return value of -1 is also a valid time_t corresponding to 31-DEC-1969 23:59:59 GMT. How do we distinguish between the two? Here's a sample program: #include <time.h> #include <strings.h> #include <string.h> #include <stdio.h> main() { struct tm stm; time_t timet; memset(&stm, 0, sizeof(stm)); putenv("TZ=GMT0"); stm.tm_sec = 59; stm.tm_min = 59; stm.tm_hour = 23; stm.tm_mday = 31; stm.tm_mon = 11; stm.tm_year = 69; stm.tm_isdst = -1; timet = mktime(&stm); printf("timet = %ld\n",timet); } thanks, - Tom

4 4

Re: tztab changes for HPUX
by ado Feb. 12, 1996

Feb. 12, 1996

Current versions of the public-domain time zone package do the right thing for October, 1995: Script started on Mon Feb 12 10:53:47 1996 elsie$ ./zdump -v Europe/London | grep 1995 Europe/London Sun Mar 26 00:59:59 1995 GMT = Sun Mar 26 00:59:59 1995 GMT isdst=0 Europe/London Sun Mar 26 01:00:00 1995 GMT = Sun Mar 26 02:00:00 1995 BST isdst=1 Europe/London Sun Oct 22 00:59:59 1995 GMT = Sun Oct 22 01:59:59 1995 BST isdst=1 Europe/London Sun Oct 22 01:00:00 1995 GMT = Sun Oct 22 01:00:00 1995 GMT isdst=0 elsie$ exit script done on Mon Feb 12 10:54:36 1996 Howmsoever...the references to and excerpts from "tztab" files in the articles about HPUX indicate the existence of an alternate and (presumably better) way of handling time zone stuff. If anyone has tztab insights to share with folks on the list, I'd love it. --ado

2 1

tzcode96d.tar.gz and tzdata96c.tar.gz
by ado Feb. 12, 1996

Feb. 12, 1996

Updated time zone files are available using anonymous ftp from elsie.nci.nih.gov (165.112.73.1) in the ~ftp/pub directory: -rw-r--r-- 1 ado 73315 Feb 12 11:05 tzcode96d.tar.gz -rw-r--r-- 1 ado 73301 Feb 12 11:05 tzdata96c.tar.gz The "code" file simply updates Bob Kridle's electronic address; the "data" file updates rules for Mexico. --ado

1 0

Re: Fault in tztab on HP-UX
by Monty Solomon Feb. 10, 1996

Feb. 10, 1996

FYI Begin forwarded message: Newsgroups: comp.sys.hp.hpux From: hmc(a)cee.hw.ac.uk (Hugh Conner) Subject: Re: Fault in tztab on HP-UX Message-Id: <DGwHBL.DI9(a)cee.hw.ac.uk> Sender: news(a)cee.hw.ac.uk (News Administrator) Organization: Dept of Computing & Electrical Engineering, Heriot-Watt University, Scotland References: <308A28E6.186D(a)ug.eds.com> Date: Mon, 23 Oct 1995 11:59:45 GMT In article <308A28E6.186D(a)ug.eds.com>, Daniel Dignam <daniel(a)ug.eds.com> writes: > There's a fault in the tztab entry for GMT0BST in 9.05, the clocks went > back today (the 22nd), but date under HP-UX is still stuck at BST :-(. > The relevant entry from tztab is as follows > > > # Greenwich Mean Time, British Summer Time > GMT0BST > 0 3 25-31 3 1983-1984 0 BST-1 > 0 3 23-29 3 1985-1990 0 BST-1 > 0 3 25-31 3 1991-2038 0 BST-1 > 0 1 25-31 10 1983-1985 0 GMT0 > 0 1 23-29 10 1986-2038 0 GMT0 > > As I understand this table it should read > > 0 1 22-29 10 1986-2038 0 GMT0 > > Anways, I guess the technology will sort itself out tomorrow, I wonder > how much breaks because of this ? The problem is that they decided to change the clocks back a week earlier than normal this year, thus screwing up all Unix systems time tables, not just HPs. I believe that next year it will be changed again so that Britain changes over at the same time as the rest of Europe, so you'll have to edit the tztab all over again. -- Hugh M. Conner hmc(a)cee.hw.ac.uk "Wot? No signature!"

1 0

tztab changes for HPUX
by Monty Solomon Feb. 10, 1996

Feb. 10, 1996

FYI Begin forwarded message: From: ajm(a)hpwin064.uksr.hp.com (Andy Monks) Newsgroups: comp.sys.hp.hpux Subject: tztab changes for HPUX Date: 23 Oct 1995 11:03:18 GMT Organization: Hewlett-Packard Message-Id: <46fspm$bhk(a)hpwin055.uksr.hp.com> -----BEGIN PGP SIGNED MESSAGE----- Dear Customer, Recent legislation has redefined the date at which we change between British Summer Time and Greenwich Mean Time. In 1995 we will return to GMT on 22nd October at 02:00 BST. The timezone adjustment table supplied with HP-UX does not take these legislative changes into account, and therefore modifications must be made if the time change is to take place correctly. The file to be modified is /usr/lib/tztab; it can be modified using vi. The section for British time is headed with the line "# Greenwich Mean Time, British Summer Time", and the table beneath it must be modified to resemble the table below: # Greenwich Mean Time, British Summer Time GMT0BST 0 3 25-31 3 1983-1984 0 BST-1 0 3 23-29 3 1985-1990 0 BST-1 0 3 25-31 3 1991-1994 0 BST-1 0 2 25-31 3 1995-2038 0 BST-1 0 1 25-31 10 1983-1985 0 GMT0 0 1 23-29 10 1986-1994 0 GMT0 0 1 21-27 10 1995 0 GMT0 0 1 25-31 10 1996-2038 0 GMT0 Note: The character 0 is the number zero in all cases include the GMT0BST line. IF THESE MODIFICATIONS ARE NOT MADE, YOUR SYSTEM WILL NOT CHANGE TO GMT ON 22ND OCTOBER THIS YEAR. It is also important to restart the cron daemon. If you need any further information, please contact the Hewlett-Packard Response Centre on 01344-366366. Yours faithfully, The Response Centre -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMIt1+zjIE3zxzhaxAQHcoQQA1JEkjfFdwIDdKnCO1yAX1y9b/dJtU6aB uUAeBbZuONFAWJLlbkVO0FwU2RvXAGfbiApTQapxwlL2RBkU4u23Yynu+D6c4/Zy sK3LcHy2acBY3CTV1tr9py+Ya3v5ZdkiYnM726JGJhDJ3QefKMKkpQRnev3zlkUz QRK8WlbPbWU= =OJEn -----END PGP SIGNATURE-----

1 0

proposed patch for Mexico
by Paul Eggert Feb. 10, 1996

Feb. 10, 1996

I asked on the net about Mexico's DST rule change this year; the most authoritative-sounding response I got was from Kevin Pitts, so I've included his version in the patch proposed below. Further corrections may be needed, since there seems to be some confusion about the changes; e.g. in http://mexico-travel.com/mex_eng.html, Mexico's Ministry of Tourism claims that Mexico switched to US style DST rules way back in spring 1994. =================================================================== RCS file: RCS/northamerica,v retrieving revision 1995.13 retrieving revision 1995.13.1.1 diff -c -r1995.13 -r1995.13.1.1 *** northamerica 1995/12/21 17:18:31 1995.13 --- northamerica 1996/02/10 04:40:26 1995.13.1.1 *************** *** 852,857 **** --- 852,866 ---- # Shanks also says there are four zones, but disagrees about the fourth. # Instead of GMT-6 with DST, he says there's GMT-8 without DST. + # From Paul Eggert (1996-02-07): + # Today in news:4f90v4$g6g@news.internet.com.mx, Kevin Pitts + # <bravo2(a)internet.com.mx> wrote that Mexico will use Horario de Verano (DST) + # starting this year with the same rules as the US, and gave FIDE as a source. + # (FIDE is a private organization that promotes efficient electrical use.) + # On 1996-02-02 Mario Camou wrote that the transition times are Apr Sun>=1 + # 0:00 and Nov 1 0:00 but also wrote ``The DST-out date looks a bit fishy''. + # Go with Pitts after 1996, and with Shanks before that. + # From Shanks (1991): # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mexico 1922 only - Jan 1 0:00 0 S *************** *** 863,868 **** --- 872,880 ---- Rule Mexico 1944 only - May 1 0:00 0 S Rule Mexico 1950 only - Feb 12 0:00 1:00 D Rule Mexico 1950 only - Jul 30 0:00 0 S + Rule Mexico 1996 max - Apr Sun>=1 2:00 1:00 D + Rule Mexico 1996 max - Oct lastSun 2:00 0 S + # Rule BajaN 1950 1966 - Apr lastSun 2:00 1:00 D Rule BajaN 1950 1961 - Sep lastSun 2:00 0 S Rule BajaN 1961 1966 - Oct lastSun 2:00 0 S *************** *** 883,902 **** -6:00 - CST 1942 Apr -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 ! -7:00 - MST Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 -8:00 - PST 1927 Jun 10 23:00 -7:00 - MST 1930 Nov 16 -8:00 - PST 1942 Apr -7:00 - MST 1949 Jan 14 -8:00 BajaN P%sT 1967 Apr lastSun 2:00 ! -8:00 US P%sT Zone America/Ensenada -7:46:28 - LMT 1922 Jan 1 0:13:32 -8:00 - PST 1927 Jun 10 23:00 -7:00 - MST 1930 Nov 16 -8:00 - PST 1942 Apr -7:00 - MST 1949 Jan 14 ! -8:00 - PST # # Revillagigedo Is # no information --- 895,916 ---- -6:00 - CST 1942 Apr -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 ! -7:00 Mexico M%sT Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 -8:00 - PST 1927 Jun 10 23:00 -7:00 - MST 1930 Nov 16 -8:00 - PST 1942 Apr -7:00 - MST 1949 Jan 14 -8:00 BajaN P%sT 1967 Apr lastSun 2:00 ! -8:00 US P%sT 1996 ! -8:00 Mexico P%sT Zone America/Ensenada -7:46:28 - LMT 1922 Jan 1 0:13:32 -8:00 - PST 1927 Jun 10 23:00 -7:00 - MST 1930 Nov 16 -8:00 - PST 1942 Apr -7:00 - MST 1949 Jan 14 ! -8:00 - PST 1996 ! -8:00 Mexico P%sT # # Revillagigedo Is # no information

1 0

DST in Mexico
by Alan.Perry＠Eng.Sun.COM Feb. 3, 1996

Feb. 3, 1996

This is what I got from our Mexico subsidiary. ------------- Begin Forwarded Message ------------- Date: Fri, 02 Feb 1996 19:38:38 -0600 From: Mario Camou - Sun Mexico Hi Alan, I finally got the info: DST-in date: 1st Sunday in April @ midnight (0:00) (bump clock 1 hour forward) DST-out date: October 31st @ midnight (24:00) (bump clock 1 hour back) TZ's affected: All of Mexico (Mexico/General, Mexico/BajaNorte and Mexico/BajaSur) The DST-out date looks a bit fishy, I'd think it more logical to put it @ the last sunday in October or something like that. However, this is the info I was able to get, and since I'm travelling to Los Angeles next week I thought it better to forward it to you now. -------------- End Forwarded Message --------------

1 0