- tz - lists.iana.org

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

Feb. 19, 1996

Hi Valery, > My man page on mktime() (Solaris2) clearly says that 'tm_year > of the tm structure must be for year 1970 or later.' This would seem to limit the usefulness of timezone rules prior to 1970 with respect to mktime(). Perhaps they did this for standards compliance? thanks, - Tom

2 3

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

Feb. 16, 1996

>> Call localtime() on the seemingly-in-error mktime() result, and compare >> the relevant portions of the structs tm. A match implies a non-error. > This doesn't sound very stable, but perhaps there is no other alternative. I'm not sure of what you mean by stable. This is, after all, exactly what mktime() does to determine is has the matching time_t. > Of course, we only need to check this > when the return of mktime() is -1 Exactly what I meant by "Call localtime() on the seemingly-in-error mktime() result."

2 1

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

Feb. 16, 1996

> > 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. > > This still doesn't tell me whether the -1 return from mktime() meant > that the time was not representable. It does tell me whether it is > representable one second later. If a particular implementation of > mktime() doesn't support times before the Epoch (and that seems okay > as far as the standards go), then a return of 0 resulting from bumping > the tm_sec up by 1 would lead me to the wrong conclusion concerning my > original call. Oops...point well taken! Would subtracting one from tm_sec (and looking for a return of -2) work? --ado

1 0

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