- tz - lists.iana.org

FW: Mongolia no DST?
by Olson, Arthur David (NIH/NCI) Oct. 22, 2002

Oct. 22, 2002

-----Original Message----- From: Jesper Nørgaard [mailto:jnorgard@Prodigy.Net.mx] Sent: Tuesday, October 22, 2002 12:07 AM To: 'TZ mailing list' Subject: Mongolia no DST? I noticed that there is no DST for Mongolia for 2002. Is that a deliberate decision, or is it because we have no "max" rule instead of "only" rules? I don't recall having seen any decision that they were taken off using DST during the year. Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

1 0

Mongolia no DST?
by Jesper Nørgaard Oct. 22, 2002

Oct. 22, 2002

I noticed that there is no DST for Mongolia for 2002. Is that a deliberate decision, or is it because we have no "max" rule instead of "only" rules? I don't recall having seen any decision that they were taken off using DST during the year. Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

1 0

Re: FW: About rules for Brazil
by John Cowan Oct. 21, 2002

Oct. 21, 2002

Paul Eggert scripsit: > In this month's case you would be right, of course; but I suspect that > it will be just as common for the clocks to be advanced ahead of our > guess as behind, and there your proposed strategy would fail just as > badly as the tz database's current approach. However, I think the important point is that the database not impose guesses about the utterly uncertain future. It is fair enough to guess that U.S. DST will stay the same, since it has been quite stable. But guessing that next year in Brazil will be like last year, when last year was not like the year before, and so on, strikes me as bogus. In short, I agree that "only" should be the rule here. > A similar situation obtains in Israel, where the guesses after 2004 > are quite arbitrary. However, for the few applications that need > access to future civil time (planning airplane trips?) I think it > better to have a good guess than to guess that there will be no DST at > all. I see your point, but in fact airplane trips are *not* the only case. Any time you make an appointment to do something or meet someone in the future, you are implicitly making it in civil time for the place of the appointment. If I say to someone "Meet me under the Waverley [that's a place in Manhattan] at midnight, New Year's Eve 2004" , then the appointment is set for midnight *local time* whatever that may be. For a more commercial example, when a stock tender or a futures option expires as of 5 PM, New York time, on such-and-such a day, that means at whatever GMT time Congress decrees is equal to 5 PM New York time *as of that day*. I have been for some years now telling people who are not on this mailing list that it is safe to use GMT or GMT+offset for present and past times, but that when an application stores future times, it should store a local time and a timezone name. Even this is not infallible -- we don't know how the TZ system will work in the year 2076 -- but it's a lot better than storing a GMT+offset and hoping nothing weird happens. -- John Cowan <jcowan(a)reutershealth.com> http://www.reutershealth.com http://www.ccil.org/~cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. -- Calvin, giving Newton's First Law "in his own words"

1 0

FW: About rules for Brazil
by Olson, Arthur David (NIH/NCI) Oct. 21, 2002

Oct. 21, 2002

Paulo is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Paulo Alexandre Pinto Pires [mailto:p@ppires.org] Sent: Monday, October 21, 2002 12:16 PM To: tz(a)lecserver.nci.nih.gov Subject: About rules for Brazil Hello, folks. I have recently downloaded tzdata 2002d, which brings new rules for Brazil again, because the government again changed when summer time starts. I suggest that rules for Brazil don't ever be considered permanent, i.e., make no use of "max" for new rules, but instead use "only". Regardless of a public poll at National Obversatory's (ON is the official source of time information for the country) web site, to learn if Brazilians would like to have fixed dates for start and end of summer time, the dates were changed again because of plain stupidity -- Electoral authorities forgot about summer time at all, and because of stupid machine programming, start of summer time had to be delayed. It is certain that the new rules will not be used in the next year, when there will be no elections, and this delay (hopefully) will not be necessary. Reading the source file for timezone data for Brazil is a joke. Things like a mayor who tries to change time in his city, and authorities forgetting about summer time in planning important occasions are everywhere. Not having fixed rules is a major cause of such a mess. This year, the decree stating that summer time should begin not on the second Sunday of October (yet no such decree ever existed before -- each ear a _new_ decree said "it starts on day X and ends on day Y"), but later, was published by the end of its first week, and not reflected on ON's web site, where most of us used to find such rules. The result is that many people, again, had their clocks wrong. I believe that if clocks eventually go wrong, it would be better if they just remained in the regular time. The effect of not advancing the clock causes less impact (and surprises) than having it unexpectly be one hour ahead.of what users think it should be, because of assuming that rules for the previous year will be used again (even though it sounds very reasonable to our technical ears). So, we now have Rule Brazil 2001 max - Feb Sun>=15 0:00 0 - Rule Brazil 2002 only - Nov 3 0:00 1:00 S Rule Brazil 2003 max - Oct Sun>=8 0:00 1:00 S but this is wrong, if nothing else, at least because of one very simple reason (already mentioned): "Oct Sun>=8" or "Feb Sun>=15" may look like a good aproach, and result of careful observation by some of us, but they are not in any previous decree, and assuming it may fail in the future again (and it fails in the past too, if we start looking back. as far as 1998 and before). Let's not go beyong the facts we know, that is we know when summer time starts in 2002 and ends in 2003, and nothing more. Besides that, let those of us who are Brazilians try to push the goverment into using permanent criterion, so that mess doesn't happen again. (BTW, I didn't have problems this year, because when I noticed that ON didn't publish anything until last year's start date was to close, I dug the Net and found this year's decree). -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

2 1

help
by Steve Mann Oct. 21, 2002

Oct. 21, 2002

1 0

About rules for Brazil
by Paulo Alexandre Pinto Pires Oct. 21, 2002

Oct. 21, 2002

Hello, folks. I have recently downloaded tzdata 2002d, which brings new rules for Brazil again, because the government again changed when summer time starts. I suggest that rules for Brazil don't ever be considered permanent, i.e., make no use of "max" for new rules, but instead use "only". Regardless of a public poll at National Obversatory's (ON is the official source of time information for the country) web site, to learn if Brazilians would like to have fixed dates for start and end of summer time, the dates were changed again because of plain stupidity -- Electoral authorities forgot about summer time at all, and because of stupid machine programming, start of summer time had to be delayed. It is certain that the new rules will not be used in the next year, when there will be no elections, and this delay (hopefully) will not be necessary. Reading the source file for timezone data for Brazil is a joke. Things like a mayor who tries to change time in his city, and authorities forgetting about summer time in planning important occasions are everywhere. Not having fixed rules is a major cause of such a mess. This year, the decree stating that summer time should begin not on the second Sunday of October (yet no such decree ever existed before -- each ear a _new_ decree said "it starts on day X and ends on day Y"), but later, was published by the end of its first week, and not reflected on ON's web site, where most of us used to find such rules. The result is that many people, again, had their clocks wrong. I believe that if clocks eventually go wrong, it would be better if they just remained in the regular time. The effect of not advancing the clock causes less impact (and surprises) than having it unexpectly be one hour ahead.of what users think it should be, because of assuming that rules for the previous year will be used again (even though it sounds very reasonable to our technical ears). So, we now have Rule Brazil 2001 max - Feb Sun>=15 0:00 0 - Rule Brazil 2002 only - Nov 3 0:00 1:00 S Rule Brazil 2003 max - Oct Sun>=8 0:00 1:00 S but this is wrong, if nothing else, at least because of one very simple reason (already mentioned): "Oct Sun>=8" or "Feb Sun>=15" may look like a good aproach, and result of careful observation by some of us, but they are not in any previous decree, and assuming it may fail in the future again (and it fails in the past too, if we start looking back. as far as 1998 and before). Let's not go beyong the facts we know, that is we know when summer time starts in 2002 and ends in 2003, and nothing more. Besides that, let those of us who are Brazilians try to push the goverment into using permanent criterion, so that mess doesn't happen again. (BTW, I didn't have problems this year, because when I noticed that ON didn't publish anything until last year's start date was to close, I dug the Net and found this year's decree). -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

1 0

Brazil DST errors
by Rainer Brockerhoff Oct. 17, 2002

Oct. 17, 2002

Hi, I've just downloaded a version of your timezone files from GNU.org, as your FTP server seems to be down. There are several errors regarding Brazil... details are on my weblog at: http://www.brockerhoff.net/bb/viewtopic.php?p=90#90 I'd be happy to send you an update, but am unsure of the precise format you require. My current TZ file is for Mac OS X only. Thanks! -- Rainer Brockerhoff <rainer(a)brockerhoff.net> Belo Horizonte, Brazil "I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams) http://www.brockerhoff.net/ now with forums for XRay, Zingg! et al.

1 0

Brazil and summer time
by Pablo Borges Oct. 16, 2002

Oct. 16, 2002

Hi. I work at uol.com.br (a major brazilian ISP) and I experience problems with our "messy" summer time decree's. So this year we made the following changes to your's southamerica Rules: Yours: Rule Brazil 2003 max - Oct Sun>=8 0:00 1:00 S to Ours: Rule Brazil 2003 only - Oct 15 0:00 1:00 S This avoids to *major* problems. The first, when we set up a 'max' rule, this rule is valid to every year after, so, when the government delays the decree, we happen to see all our machines entering the 'summer time' way before the correct date. The second, the decree says February 15th, and not the first sunday after February 8th, as says your rule. I hope this helps. []'s Pablo Borges UOL sysadmin -- "Don't get me wrong: Emacs is a great operating system---it lacks a good editor, though." Quote from the "VI LOVERS HOMEPAGE" http://www.thomer.com/vi/vi.html

1 0

new southamerica timezone patch
by Marcus Felipe Pereira (Akim) Oct. 15, 2002

Oct. 15, 2002

1 0

tzcode2002d.tar.gz and tzdata2002d.tar.gz
by Olson, Arthur David (NIH/NCI) Oct. 15, 2002

Oct. 15, 2002

The files ftp://elsie.nci.nih.gov/pub/tzcode2002d.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2002d.tar.gz are now available. They incorporate the changes circulated last week on the time zone mailing list by Paul Eggert, less the "Britain (UK)" change in iso3166.tab. There's also a new time zone quote in "tz-art.htm." Note that our lab is due to move from the third to the fourth floor of our building this week; some outages in the availability of elsie.nci.nih.gov are to be expected. Download early. --ado Return-Path: <> Received: from spf12.us4.outblaze.com (205-158-62-36.outblaze.com [205.158.62.36]) by lecserver.nci.nih.gov (8.12.3/8.12.3) with ESMTP id g9FHOVqU003272 for <tz-request(a)lecserver.nci.nih.gov>; Tue, 15 Oct 2002 13:24:31 -0400 (EDT) Received: from localhost (localhost) by spf12.us4.outblaze.com (8.12.5/8.12.5/us4-yg) id g9FHNH2V019899; Tue, 15 Oct 2002 17:23:17 GMT Date: Tue, 15 Oct 2002 17:23:17 GMT From: Mail Delivery Subsystem <MAILER-DAEMON> Message-Id: <200210151723.g9FHNH2V019899(a)spf12.us4.outblaze.com> To: <tz-request(a)lecserver.nci.nih.gov> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g9FHNH2V019899.1034702597/spf12.us4.outblaze.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g9FHNH2V019899.1034702597/spf12.us4.outblaze.com The original message was received at Tue, 15 Oct 2002 17:23:16 GMT from 205-158-62-26.outblaze.com [205.158.62.26] ----- The following addresses had permanent fatal errors ----- <"yiango:programmer.net"@iname.com.int> (reason: 552 recipient storage full, try again later) ----- Transcript of session follows ----- ... while talking to mta1.us4.outblaze.com.: >>> DATA <<< 552 recipient storage full, try again later 554 5.0.0 Service unavailable <<< 503 RCPT first (#5.5.1) --g9FHNH2V019899.1034702597/spf12.us4.outblaze.com Content-Type: message/delivery-status Reporting-MTA: dns; spf12.us4.outblaze.com Received-From-MTA: DNS; 205-158-62-26.outblaze.com Arrival-Date: Tue, 15 Oct 2002 17:23:16 GMT Final-Recipient: RFC822; "yiango:programmer.net"@iname.com.int Action: failed Status: 5.2.2 Remote-MTA: DNS; mta1.us4.outblaze.com Diagnostic-Code: SMTP; 552 recipient storage full, try again later Last-Attempt-Date: Tue, 15 Oct 2002 17:23:17 GMT --g9FHNH2V019899.1034702597/spf12.us4.outblaze.com Content-Type: text/rfc822-headers Return-Path: <tz-request(a)lecserver.nci.nih.gov> Received: from spf4.us4.outblaze.com (205-158-62-26.outblaze.com [205.158.62.26]) by spf12.us4.outblaze.com (8.12.5/8.12.5/us4-yg) with ESMTP id g9FHNF2V019845 for <"yiango:programmer.net"@iname.com.int>; Tue, 15 Oct 2002 17:23:16 GMT Received: from kafka.net.nih.gov (kafka.net.nih.gov [165.112.130.10]) by spf4.us4.outblaze.com (8.12.6/8.12.6) with ESMTP id g9FHONVn021816 for <yiango(a)programmer.net>; Tue, 15 Oct 2002 17:24:23 GMT Received: from lecserver.nci.nih.gov (elsie.nci.nih.gov [137.187.215.78]) by kafka.net.nih.gov (/8.10.1) with ESMTP id g9FHLG4V010999; Tue, 15 Oct 2002 13:21:16 -0400 (EDT) Received: from lecserver.nci.nih.gov (localhost [127.0.0.1]) by lecserver.nci.nih.gov (8.12.3/8.12.3) with ESMTP id g9FHLGqU003118; Tue, 15 Oct 2002 13:21:16 -0400 (EDT) Received: (from ado@localhost) by lecserver.nci.nih.gov (8.12.3/8.12.3/Submit) id g9FHLDHj003109; Tue, 15 Oct 2002 13:21:13 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 13:21:13 -0400 (EDT) X-Authentication-Warning: lecserver.nci.nih.gov: ado set sender to tz-request(a)elsie.nci.nih.gov using -f Message-ID: <CFC0DFECD5F33B46A67BAD80B618EEA15AA9FF(a)nihexchange2.nih.gov> From: "Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> To: "List Time Zone (E-mail)" <tz(a)lecserver.nci.nih.gov> Subject: tzcode2002d.tar.gz and tzdata2002d.tar.gz Date: Tue, 15 Oct 2002 13:20:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"hHQ32C.A.st.-5Er9"@lecserver> Resent-From: tz(a)lecserver.nci.nih.gov X-Mailing-List: <tz(a)elsie.nci.nih.gov> archive/latest/1509 X-Loop: tz(a)elsie.nci.nih.gov Precedence: list Resent-Sender: tz-request(a)lecserver.nci.nih.gov --g9FHNH2V019899.1034702597/spf12.us4.outblaze.com-- Return-Path: <drepper(a)redhat.com> Received: from myware.akkadia.org (cpe-24-221-190-179.ca.sprintbbd.net [24.221.190.179]) by lecserver.nci.nih.gov (8.12.3/8.12.3) with ESMTP id g9FHtsqU003527 for <tz(a)lecserver.nci.nih.gov>; Tue, 15 Oct 2002 13:55:55 -0400 (EDT) Received: from redhat.com (myware.akkadia.org [192.168.7.70]) (authenticated bits=0) by myware.akkadia.org (8.12.5/8.12.5) with ESMTP id g9FHtcDX017011; Tue, 15 Oct 2002 10:55:38 -0700 Message-ID: <3DAC569A.6060705(a)redhat.com> Date: Tue, 15 Oct 2002 10:55:38 -0700 From: Ulrich Drepper <drepper(a)redhat.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021014 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> CC: "List Time Zone (E-mail)" <tz(a)lecserver.nci.nih.gov> Subject: Re: tzcode2002d.tar.gz and tzdata2002d.tar.gz References: <CFC0DFECD5F33B46A67BAD80B618EEA15AA9FF(a)nihexchange2.nih.gov> In-Reply-To: <CFC0DFECD5F33B46A67BAD80B618EEA15AA9FF(a)nihexchange2.nih.gov> X-Enigmail-Version: 0.65.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olson, Arthur David (NIH/NCI) wrote: > The files > ftp://elsie.nci.nih.gov/pub/tzcode2002d.tar.gz > and > ftp://elsie.nci.nih.gov/pub/tzdata2002d.tar.gz > are now available. They incorporate the changes circulated last week > on the > time zone mailing list by Paul Eggert, > less the "Britain (UK)" change in iso3166.tab. Are you sure the new data is included? I downloaded said files and the southamerica file in tzdata doesn't look any different than the 2002c version. Thanks, - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rFaa2ijCOnn/RHQRAiTtAKCQ8lyltfkF0KA5KpbXUMW9XzsoAgCgwndf wT8/2l1teXbAcHCwHus7Yro= =d1c/ -----END PGP SIGNATURE-----

2 1