- tz - lists.iana.org

FW: UK Timezone info
by Olson, Arthur David (NCI) May 12, 1999

May 12, 1999

Note that Robert Brady is not on the time zone mailing list. --ado -----Original Message----- From: Robert Brady [SMTP:rwb197@ecs.soton.ac.uk] Sent: Wednesday, May 12, 1999 12:11 PM To: tz(a)elsie.nci.nih.gov Subject: UK Timezone info You'll like this : the power to set time-zone in the UK might be devolved to the Scottish Parliamant and Welsh Assembly. See : http://www.parliament.the-stationery-office.co.uk/pa/ld199899/ldbills/047/1… 7.htm -- Robert.

1 0

UK Timezone info
by Robert Brady May 12, 1999

May 12, 1999

You'll like this : the power to set time-zone in the UK might be devolved to the Scottish Parliamant and Welsh Assembly. See : http://www.parliament.the-stationery-office.co.uk/pa/ld199899/ldbills/047/1… -- Robert.

1 0

FW: FW: Australian Timezone issues.
by Olson, Arthur David (NCI) May 11, 1999

May 11, 1999

-----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Tuesday, May 11, 1999 4:30 AM To: 'tz' Cc: Robert Elz Subject: Re: FW: Australian Timezone issues. Robert Elz wrote: > | Has any thought been given to having the Australian EST timezone renamed > | to AEST? > > No. Or at least, I certainly hope it has not. why? > | For example, when a database dumps a time 'Sun May 9 11:07:06 > | EST 1999 in Australia, and then the database reads the time back in, it > | assumes that EST is New York time and everything gets screwed up. > > Any code that does that is simply broken. Time zone names > are a hint to humans. They simply aren't unambiguous. The > two Aust zone abbreviations that are the same as their US > equivalents (EST and CST) aren't the only ambiguous ones > around (and then there are all the places that have no real > concept of a timezone name at all - and the tz database > just invents one for them - most of the countries in South > East Asia are given "ICT", which seems to be "Indo China > Time" which, as a label, means nothing locally > at all). Well I'll report that to the database developers. If that is the official way it is, and it's not just Australia in this boat, then I guess things have to change in how people write code. This is a quote from the POSTGRESQL database documentation... "If the compiler option USE_AUSTRALIAN_RULES is set then EST refers to Australia Eastern Std Time, which has an offset of +10:00 hours from UTC. Australian time zones and their naming variants account for fully one quarter of all time zones in the Postgres time zone lookup table." > | reports when TZ=EST. > > You give ambiguous input, you can expect to get ambiguous ouput. > If you want to specify Australian time, use > TZ=Australia/Sydney or whatever, and for North American, > use TZ=America/New_York. But there doesn't seem to be a portable way to find out the string "Australia/Sydney" on your computer. Everything would be fine and dandy if strftime() returned the zone as "Australia/Sydney", but that's not what it does, it returns the mnumonic EST buried inside the zone file. If the mnumonic was "Australia/Sydney" then fine, but it's not. > You need to > be more precise than just "eastern" anyway to represent > historical times accurately. Well, current times would be a start. > Alternatively, convince the whole world that time zone > names ought always have a country, or region prefix - > perhaps we could have "American Eastern Standard Time" (not > US, as it applies in Canada, and perhaps parts of > Mexico and other parts of Central America as well) and > Australian Eastern Standard Time, and both could be AEST Do we have to convince the world, or merely UNIX operating system vendors? After all, as you say zone names are ambiguous now, so nobody can be relying on them for other than (potentially inaccurate) information. So making them unique could only improve things no? > Time zone names are just an inherantly local phenomenon - > anything, anywhere, which intends to write, and then parse, > a date string needs to be sure that the string contains the > numeric zone offset. Even humans which don't carry time offsets and summer time rules around in their heads?

1 0

FW: Australian Timezone issues.
by Olson, Arthur David (NCI) May 11, 1999

May 11, 1999

Note that Chris is not on the time zone mailing list; be sure that any replies are directed to Chris. --ado -----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Sunday, May 09, 1999 11:12 AM To: tz(a)elsie.nci.nih.gov Subject: Australian Timezone issues. I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files. Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long. AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything. For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up. Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what? As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time. This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST. What would have to be done to get this changed in the zoneinfo files? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com

4 8

When Citizens Disagree on Even the Time of Day
by Paul Eggert May 10, 1999

May 10, 1999

On today's op-ed page of the LA Times, Jorge G. Castan~eda, a political scientest and writer in Mexico City, used time zones as a metaphor for the political fragmentation and social dissolution of today's Mexico. Among other things, he writes: One example involves the time zones in the country and the absurd debate that took place in March as to who would adopt daylight saving time. Some states have adopted the hour change, others have not. Some are on U.S. Central time, some on Mountain time and some on Pacific time, while the one that used to go by Eastern time--Quintana Roo, where Cancun is located--decided to go back to Central time. While Mexico City Mayor Cuauhtemoc Cardenas wisely desisted from heeding his rank and file and accepted the federal government's decision to move clocks forward on April 1, it was touch and go for several days. The country cannot even agree, literally, on the time of day. I assume that the ``April 1'' here was the date of Cardenas's decision, not the date the clocks actually moved (which was presumably April 4 as usual in North America these days). We know about Quintana Roo and have some idea of states that fall into all the categories mentioned above, but it perhaps some states have changed since last year, and it would be useful to know exactly what happened in Mexico this spring. Reference: http://www.latimes.com/HOME/NEWS/COMMENT/t000041976.1.html

2 1

Australian Timezone issues.
by Chris Bitmead May 9, 1999

May 9, 1999

I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files. Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long. AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything. For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up. Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what? As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time. This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST. What would have to be done to get this changed in the zoneinfo files? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com

1 0

Re: FW: POSIX-TZ without rules
by Guido Flohr May 5, 1999

May 5, 1999

On Thu, Apr 29, 1999 at 04:39:29PM -0700, Paul Eggert wrote: > From: Guido Flohr [SMTP:gufl0000@stud.uni-sb.de] > Sent: Monday, April 26, 1999 9:46 PM > > for testing purposes I set the envariable TZ to "CET-1CEST-2", > i. e. a valid POSIX-style string but without explicit rules. > I also uninstalled the database for that test. > > Under these circumstances tzparse() in localtime.c will return an error > because it fails to open a default rules file. From what I remember I > would say that POSIX demands that the US rules should be applied instead. > > POSIX.1 is not US-centric here; it says that the behavior in this case > is implementation-defined. The rationale (POSIX 1003.1-1996 section > B.8.1.1 page 493 lines 5609-5612) says ``An implementation may provide > those rules [i.e. the DST rules not explicitly specified by the user] OK, I'll never use the word POSIX again. ;-) My information is only second hand. > Anyway, "CET-1CEST-2" is perfectly POSIX-compliant and the library should > not return an error then. > > Yes. My reading of POSIX.1 is that the implementation is allowed to > guess the DST rules, but it's not allowed to fail. I agree. A popular German Unix guide recommends "CET-1CEST-2" as the default TZ setting for Germany, German HP-UX distributions use it to (well, with "MET" instead of "CET"). > The GNU libc handles this case by assuming an implicit rule of > "M4.1.0,M10.5.0" (commented as "US Federal Law"). My solution is somewhat > different: I generated a header "new_york.h" > > Both solutions have problems. The first mishandles old dates; the > second assumes the New York City DST rules, whereas it'd be better to > assume only the US rules. Implementing the plain US rules (back to > 1918) would be better; can you do this? Do you mean writing a rules file for that case (which could be compiled and hardcoded into the library)? Actually I even have problems with that solution. I think we had better leave DST alone if no rules are available. Guessing rules always means to do exactly the wrong thing for half of the world, assuming rules that are suitable for the northern hemisphere means to discriminate the southern hemisphere. Correct me if I'm wrong, but isn't it possible to explicitely mark that question as undecidable by setting tm->tm_isdst resp. the variable daylight to -1? Collecting back data which will most probably provide wrong results looks a little ridiculous to me. What should we do when time_t grows 64 bits big? Guess if Alexander arrived one hour early at Issos because the Greek had DST and the Persians hadn't? > > In zic.c, the analysis of the return value of > system("yearistype ...") assumes a certain structure of that return value. > > That's clearly a portability bug; here's a patch. Fine. > +#if HAVE_SYS_WAIT_H - 0 > +#include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ > +#endif /* HAVE_SYS_WAIT_H - 0 */ > + > +#ifndef WIFEXITED > +#define WIFEXITED(status) (((status) & 0xff) == 0) > +#endif /* !defined WIFEXITED */ > +#ifndef WEXITSTATUS > +#define WEXITSTATUS(status) (((status) >> 8) & 0xff) > +#endif /* !defined WEXITSTATUS */ Will that work on BSD systems with a union wait? system() returns int, so what does BSD recommend to get the status bits? Sorry, I don't know, I just want to point out a possible problem. Ciao Guido -- http://stud.uni-sb.de/~gufl0000 mailto:gufl0000@stud.uni-sb.de

1 0

FW: accessing DST rules at runtime
by Olson, Arthur David (NCI) April 20, 1999

April 20, 1999

-----Original Message----- From: Dave Hackenyos [SMTP:hackenyo@roguewave.com] Sent: Friday, April 16, 1999 8:12 PM To: ado(a)elsie.nci.nih.gov Subject: accessing DST rules at runtime Hello, I have been working on an implementation problem about which you may have some insight. I hope you don't mind a question or two. I am attempting to discover a way to query any (most) Operating Systems about what it may think the daylight rule is for the Timezone in which it thinks it is located. I wish to do this at runtime. I am aware that a call to tzset() will set a host of information, but only a few are available to the programmer (tzname, daylight, etc). I cannot find a way to get at the exact DST rule information even though the system is well aware of it during every call of localtime(). Your tar files at elsie.nci.nih.gov are full of info about the subject and several, if not all platforms of interest to me use it. Your localtime() function seems to know how to parse these binary zoneinfo files, but once again, I am unable to discern how to access the DST rule info for my own use. My question: Could you shed some light on how (given knowledge of the path to a particular OS's zoneinfo location) one could gleen the DST rule at runtime? I would be forever in your debt. Thanks for any help you could send my way, Dave Hackenyos hackenyo(a)roguewave.com (541)754-2976

2 1

Jordan do not have DST this year
by Steffen Thorsen April 7, 1999

April 7, 1999

It also seems that they are not going to use it the next years either. "We do not need it" was the answer I got from the Jordan National Information Centre (http://www.nic.gov.jo) Best regards, Steffen

1 0

RE: new UK proposal
by Lee Geoff April 6, 1999

April 6, 1999

This might be good in the UK and very good in Germany but what about our southern EC neighbours? The Spanish would lose an hour of sleep from their siesta which sounds like a bad idea when it will be applied every day. Has anyone any bright ideas for the former Yugoslavia where the clocks seem to have been put back 50 years? Geoff. > -----Original Message----- > From: Martin Burnicki [SMTP:martin.burnicki@meinberg.de] > Sent: Tuesday, April 06, 1999 2:00 PM > To: tz(a)elsie.nci.nih.gov > Subject: Re: new UK proposal > > ***** This message originated from outside the AA ***** > > Peter Ilieve wrote: > > > > The following letter appeared in the Independent (a UK `quality' > > broadsheet paper) on 31 March, so was presumably not an April Fool > > (although I have my doubts :-): > > --- > > Time for reform > > > > Sir: I cannot be the only person who felt disoriented on Sunday > > morning after losing an hour's sleep, but who was grateful for the > > prospect of lighter evenings. Nevertheless, I feel that permanent > > British Summer Time would not be appropriate because of excessively > > long dark mornings in Scotland, and the loss of October's extra > > hour in bed would be hard to bear. > > May I therefor suggest that the country adopts Greenwich Mean Time > > in the mornings, and BST in the afternoons? The clocks could go > > forward after lunch and back around 2am. This would reduce the > > working week (currently far too long for most people) and give > > everyone an extra hour in bed every night. Evenings would be lighter, > > and mornings not too dark in winter. Why has nobody thought of this > > > before? > > > > John Parker > > London N3 > > --- > > > > Peter Ilieve peter(a)aldie.co.uk > > I think this is a VERY good idea. But remember we're the European > Community. That rule to determine beginning/end of daylight saving > should be used all over Europe, so we would also benefit from it in > Germany ;-) > > -- > > M. Burnicki > > Meinberg Funkuhren > Bad Pyrmont > Germany

1 0

new UK proposal
by peter＠aldie.co.uk April 6, 1999

April 6, 1999

The following letter appeared in the Independent (a UK `quality' broadsheet paper) on 31 March, so was presumably not an April Fool (although I have my doubts :-): --- Time for reform Sir: I cannot be the only person who felt disoriented on Sunday morning after losing an hour's sleep, but who was grateful for the prospect of lighter evenings. Nevertheless, I feel that permanent British Summer Time would not be appropriate because of excessively long dark mornings in Scotland, and the loss of October's extra hour in bed would be hard to bear. May I therefor suggest that the country adopts Greenwich Mean Time in the mornings, and BST in the afternoons? The clocks could go forward after lunch and back around 2am. This would reduce the working week (currently far too long for most people) and give everyone an extra hour in bed every night. Evenings would be lighter, and mornings not too dark in winter. Why has nobody thought of this before? John Parker London N3 --- Peter Ilieve peter(a)aldie.co.uk

3 2

FW: Timezone data
by Olson, Arthur David (NCI) April 6, 1999

April 6, 1999

Be sure replies are directed to Len Landau, who's not on the time zone mailing list. --ado -----Original Message----- From: Les Landau [SMTP:Les.Landau@digital.com] Sent: Monday, April 05, 1999 7:47 PM To: tz(a)elsie.nci.nih.gov Subject: Timezone data Hi, I got this e-mail address from www.timezone.com - I hope its OK to ask your advice. I'm trying to write a Visual Basic application to convert times between zones, and would like to get a database of timezone info in a form that I can read. Are you aware of a database that could be read by a windows application? Is there any documentation of its structure? Any help is most appreciated. Cheers, Les ---------------------------------------------------------------------------- ------------ Les Landau LanNet Services E-mail: LandauL(a)ozemail.com.au 8 Solander Place Phone: 0419 825242 Yarralumla Fax: 02 6282 8433 ACT 2600 Australia

1 0

Timezone data
by Les Landau April 5, 1999

April 5, 1999

Hi, I got this e-mail address from www.timezone.com - I hope its OK to ask your advice. I'm trying to write a Visual Basic application to convert times between zones, and would like to get a database of timezone info in a form that I can read. Are you aware of a database that could be read by a windows application? Is there any documentation of its structure? Any help is most appreciated. Cheers, Les ---------------------------------------------------------------------------- ------------ Les Landau LanNet Services E-mail: LandauL(a)ozemail.com.au 8 Solander Place Phone: 0419 825242 Yarralumla Fax: 02 6282 8433 ACT 2600 Australia

1 0

New RFC about time
by Antoine Leca April 2, 1999

April 2, 1999

A new RFC about time have been issued recently. from rfc-index 2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. April-01-1999. (Format: TXT=28011 bytes) (Status: INFORMATIONAL) It is available from your favorite RFC repository. Worth consulting it. Antoine

1 0

storing timestamp data
by Lee Geoff April 1, 1999

April 1, 1999

Maiden email from a new subscriber. My interest is less in the intricacies of a complete world view of time zone settings and more in best practice for the storage of timestamp data in computer systems. I'm interested in storing date/time data in Ingres databases which are running on Unix servers. We are recording timed events on Unix servers as well as Windows 3.1 and NT PCs. I have had problems with the apparent miss-handling of data when viewed before or after a DST transition. Can anyone point me at words of wisdom or good advice? Geoff Lee

3 2

FW: compiled zoneinfo files
by Olson, Arthur David (NCI) March 30, 1999

March 30, 1999

Please ensure that any replies go to Connie Maeder, who's not on the time zone mailing list. --ado -----Original Message----- From: Connie Maeder [SMTP:cmaeder@swissinfo.net] Sent: Monday, March 29, 1999 7:03 PM To: tz(a)elsie.nci.nih.gov Subject: compiled zoneinfo files Sirs, I would like to update my zoneinfo directory on a BSDI system. Please make a tar file with the entire compiled zoneinfo files. The update would be much easier if we could just replace the zoneinfo dir. Thanks Connie Maeder SI Online

2 1

tzcode1999d.tar.gz and tzdata1999d.tar.gz
by Olson, Arthur David (NCI) March 30, 1999

March 30, 1999

The files ftp://elsie.nci.nih.gov/pub/tzcode1999d.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1999d.tar.gz are now available. These include the changes circulated this week on the time zone mailing list by Paul Eggert; the Makefile's "make public" rule has also been changed to do a test compile of each individual time zone data file (which should help avoid problems such as the one we had with Nicosia). --ado

1 0

tzcode1999c.tar.gz and tzdata1999c.tar.gz
by Olson, Arthur David (NCI) March 30, 1999

March 30, 1999

The files ftp://elsie.nci.nih.gov/pub/tzcode1999c.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1999c.tar.gz are now available. These include the changes circulated by Paul Eggert on the time zone mailing list, most importantly the change for Chile. I tried and failed to reproduce the proglem reported by Andreas Jaeger; if anyone has insights please pass them on to both the time zone list and Andreas (who's not on the list). --ado

2 1

compiled zoneinfo files
by Connie Maeder March 30, 1999

March 30, 1999

Sirs, I would like to update my zoneinfo directory on a BSDI system. Please make a tar file with the entire compiled zoneinfo files. The update would be much easier if we could just replace the zoneinfo dir. Thanks Connie Maeder SI Online

1 0

DST in the news
by Olson, Arthur David (NCI) March 29, 1999

March 29, 1999

The 1999-03-28 exhibition baseball game held in Havana, Cuba, between the Cuban National Team and the Baltimore Orioles was carried live on the Orioles Radio Network, including affiliate WTOP in Washington, DC. During the game, play-by-play announcer Jim Hunter noted that "We'll be losing two hours of sleep...Cuba switched to Daylight Saving Time today." (The "two hour" remark referred to losing one hour of sleep on 1999-03-28--when the announcers were in Cuba as it switched to DST--and one more hour on 1999-04-04--when the announcers will have returned to Baltimore, which switches on that date.) The current "northamerica" file shows Cuba switching 1999-04-04; in view of Hunter's comment, a change may be needed in the file. --ado

1 0

Re: tzcode1999c.tar.gz and tzdata1999c.tar.gz
by Andreas Jaeger March 25, 1999

March 25, 1999

>>>>> NCI writes: > I tried and failed to reproduce the proglem reported by Andreas Jaeger; > if anyone has insights please pass them on to both the time zone list and > Andreas (who's not on the list). How did you try to reproduce it? With glibc 2.1, I can easily reproduce it with tzdata1999c (just downloaded): $ zic asia "asia", line 307: unruly zone "asia", line 307: %s in ruleless zone but `zic asia europe' works Btw. how can I subscribe to the tz list? Andreas -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 0

FW: tzdata1999b
by Olson, Arthur David (NCI) March 25, 1999

March 25, 1999

-----Original Message----- From: Andreas Jaeger [SMTP:aj@arthur.rhein-neckar.de] Sent: Friday, March 19, 1999 2:16 PM To: tz(a)elsie.nci.nih.gov Subject: tzdata1999b This morning I added tzdata1999b to glibc 2.1 and got the following failure when running make check: /usr/glibc/src/buildreport/19990319/timezone/zic -d /usr/glibc/src/buildreport/19990319/timezone/testdata -y ./yearistype asia "asia", line 308: unruly zone "asia", line 308: %s in ruleless zone The problem is: Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EU EE%sT EU isn't defined in asia and EUAsia is used instead. The appended patch fixes my problem. --- timezone/asia.~1~ Fri Mar 19 10:28:45 1999 +++ timezone/asia Fri Mar 19 18:45:04 1999 @@ -305,7 +305,7 @@ # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep - 2:00 EU EE%sT + 2:00 EUAsia EE%sT # IATA SSIM (1998-09) has Cyprus using EU rules for the first time. # Georgia -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 0

FW: update to the timezone database (Chile)
by Olson, Arthur David (NCI) March 22, 1999

March 22, 1999

-----Original Message----- From: Julio Pacheco T. [SMTP:jpacheco@atenea.ipvg.udec.cl] Sent: Thursday, March 18, 1999 9:30 PM To: tz(a)elsie.nci.nih.gov Subject: update to the timezone database (Chile) Because of the same drought , the government decided to end DST later, on April 3, (one-time change) New line on the file: Rule Chile 1999 only - Apr 4 0:00 0 - -- +--------------------------------------+------------------------------------+ | Julio I. Pacheco Troncoso | "Todo programa no trivial contiene | | Ingenieria (E) en Comp. e Inf. | al menos un error." | | Instituto Profesional Virginio Gomez | PGP key: | | mailto:jpacheco@atenea.ipvg.udec.cl | http://www.ipvg.udec.cl/~jpacheco | +--------------------------------------+------------------------------------+

2 1

Israel 1999 Daylight Savings Times -- Official Announcement
by Ephraim Silverberg March 22, 1999

March 22, 1999

The official announcement for the 1999 dates for DST in Israel has been released and scanned in to ftp://ftp.huji.ac.il/pub/tz/announcements/1999.ps.gz. The only change to the 'asia' file is in the comments. -----------------------------------CUT-HERE----------------------------------- *** asia Mon Feb 1 22:29:31 1999 --- asia.new Mon Mar 22 11:22:32 1999 *************** *** 1,4 **** ! # @(#)asia 7.41 # This data is by no means authoritative; if you think you know better, # go ahead and edit the file (and please send any changes to --- 1,4 ---- ! # @(#)asia 7.42 # This data is by no means authoritative; if you think you know better, # go ahead and edit the file (and please send any changes to *************** *** 562,574 **** # ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # # The dates for 1997-1998 were altered by his successor, Rabbi Eli Suissa. - # The official announcement for the year 1997 can be viewed at: # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/1997.ps.gz # ! # The official announcement for the year 1998 can be viewed at: # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/1998.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Mar 15 0:00 1:00 D --- 562,573 ---- # ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # # The dates for 1997-1998 were altered by his successor, Rabbi Eli Suissa. # ! # The official announcements for the years 1997-1999 can be viewed at: # ! # ftp://ftp.huji.ac.il/pub/tz/announcements/YYYY.ps.gz # ! # where YYYY is the relevant year. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 1996 only - Mar 15 0:00 1:00 D ----------------------------------UNTIL-HERE---------------------------------- ___________________________________________________________________________ Ephraim Silverberg, CS System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-6585439 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cs.huji.ac.il

1 0

tzdata1999b
by Andreas Jaeger March 19, 1999

March 19, 1999

This morning I added tzdata1999b to glibc 2.1 and got the following failure when running make check: /usr/glibc/src/buildreport/19990319/timezone/zic -d /usr/glibc/src/buildreport/19990319/timezone/testdata -y ./yearistype asia "asia", line 308: unruly zone "asia", line 308: %s in ruleless zone The problem is: Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EU EE%sT EU isn't defined in asia and EUAsia is used instead. The appended patch fixes my problem. --- timezone/asia.~1~ Fri Mar 19 10:28:45 1999 +++ timezone/asia Fri Mar 19 18:45:04 1999 @@ -305,7 +305,7 @@ # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep - 2:00 EU EE%sT + 2:00 EUAsia EE%sT # IATA SSIM (1998-09) has Cyprus using EU rules for the first time. # Georgia -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 0