- tz - lists.iana.org

RE: New date and time draft
by Jesper Nørgaard April 10, 2001

April 10, 2001

This work appeals to me a great deal, so this is not really a constructive criticism. I applaud the completely irrefutable arguments to why four-digit dates are a must in internet communication. I just have one question: Does 03-Apr-01 mean third of April 2001 or does it mean first of April 2003 (that would really be an April's Fool with a vengeance). In a few years I might wonder even more ... May you all have a nice day ... Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista 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 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://timezone50.homepage.com ---------- From: Olson, Arthur David (NCI)[SMTP:olsona@dc37a.nci.nih.gov] Sent: Lunes 9 de Abril de 2001 7:13 To: tz (E-mail) Subject: FW: New date and time draft Graham Klyne is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Graham Klyne [mailto:GK@NineByNine.org] Sent: Friday, April 06, 2001 5:11 AM To: discuss(a)apps.ietf.org; tz(a)elsie.nci.nih.gov Subject: New date and time draft FYI, I've submitted a revision of the date and time draft Chris Newman wrote some time ago. One of the goals for the current revision is to create a separate specification that answers a clear and present requirement from other parts concerning which there is less clear consensus. Specifically, this draft aims to move forward the timestamp elements of Chris' original work, while allowing the trickier "schedule events" elements to be picked up and developed by a group with more specific relevant expertise and goals, if required. #g -- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Instant Messaging and Presence Protocol Working Group of the IETF. Title : Date and Time on the Internet: Timestamps Author(s) : C. Newman, G. Klyne Filename : draft-ietf-impp-datetime-00.txt Pages : 16 Date : 03-Apr-01 This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 [ISO8601] standard for representation of dates and times using the Gregorian calendar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-00.txt ------------ Graham Klyne (GK(a)ACM.ORG)

1 0

FW: New date and time draft
by Olson, Arthur David (NCI) April 10, 2001

April 10, 2001

Graham Klyne is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Graham Klyne [mailto:GK@NineByNine.org] Sent: Friday, April 06, 2001 5:11 AM To: discuss(a)apps.ietf.org; tz(a)elsie.nci.nih.gov Subject: New date and time draft FYI, I've submitted a revision of the date and time draft Chris Newman wrote some time ago. One of the goals for the current revision is to create a separate specification that answers a clear and present requirement from other parts concerning which there is less clear consensus. Specifically, this draft aims to move forward the timestamp elements of Chris' original work, while allowing the trickier "schedule events" elements to be picked up and developed by a group with more specific relevant expertise and goals, if required. #g -- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Instant Messaging and Presence Protocol Working Group of the IETF. Title : Date and Time on the Internet: Timestamps Author(s) : C. Newman, G. Klyne Filename : draft-ietf-impp-datetime-00.txt Pages : 16 Date : 03-Apr-01 This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 [ISO8601] standard for representation of dates and times using the Gregorian calendar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-00.txt ------------ Graham Klyne (GK(a)ACM.ORG)

3 2

Re: New date and time draft
by Chris Newman April 9, 2001

April 9, 2001

Given that my office already purchased ISO 8601:1988 a few years ago, I certainly couldn't justify the cost of purchasing a revision in current tight economic times. If there's a public list of errata (or a free revision available to people who purchased the previous version), I'd be glad to vet the spec against that. Or perhaps if Graham feels like purchasing a copy and vetting the ABNF he could. Otherwise I believe we should keep the reference to the older version since that's what this spec is based on. - Chris --On Monday, April 9, 2001 18:22 +0100 Markus Kuhn <Markus.Kuhn(a)cl.cam.ac.uk> wrote: > But this document still references the old first edition! The one that > counted accidentally minutes from 01 to 60 and similar nonsense, along > with lots of ambiguities: > > [ISO8601] "Data elements and interchange formats -- Information > interchange -- Representation of dates and times", ISO > 8601:1988(E), International Organization for > Standardization, June, 1988. > > The new second edition with lots of bug fixes, ISO 8601:2000, has been > available since December and can be ordered online from > > http://www.iso.ch/cate/d26780.html

1 0

Interested in knowing about the mailing list.
by Gautam, Alok April 9, 2001

April 9, 2001

Dear Administrator, Got this id from the net. I am interested to get the mailing list of the folks who maintain the Timezone Database and the various access routines. Do favour me. Best regards, Alöok Gautam **************************************************************************** The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail at the above address (or if known by telephone or by fax). E-mail communications are not secure and therefore we do not accept any responsibility for the confidentiality or altered contents of this message. Please be aware that our company cannot accept any orders or other legally binding correspondence with a participant as part of an e-mail. The views expressed above are not necessarily those held by our company and not binding for our company. ****************************************************************************

1 0

Mexico City decree suspended
by Jesper Nørgaard April 8, 2001

April 8, 2001

There has been some new decisions and news about the summer time in Mexico, I send you some links and some resuming quotations. The interspersed english sentences are translations of the previous sentence in spanish: Da Corte revés a AMLO en horario (The Court gives a reverse to AMLO about the daylight saving rule) http://www.reforma.com/ciudad_de_mexico/articulo/085728/ Opinan magistrados que si no se otorgaba la suspensión se afectaría o alteraría la vida de los habitantes del Distrito Federal, poniendo en peligro la seguridad y economía de la sociedad. (Magistrates say that if the suspension (of the AMLO decree) was not issued, it would affect or alterate the lifes of the inhabitants of the Federal District, putting in danger the security and economy of the society) (Jesper's note: I had a good laugh about the above "opinion of the magistrates", but I guess that is just me ... :) How any daylight saving rule could affect security and economy, I guess you have to be a magistrate to grasp :) Ve AMLO 'cortina de humo' en Horario (AMLO sees a 'curtain of smoke' in the daylight saving rule) http://www.reforma.com/ciudad_de_mexico/articulo/085774/ El Jefe de Gobierno dijo que se trata sólo de una suspensión temporal del decreto y que se deberá esperar a la resolución final (The Chief of Government said that it is only a temporary suspension of the decree and that we must wait for the final judgement of the case) Avala PAN determinación de SCJN (political party PAN endorses the determination of the Court) http://www.reforma.com/ciudad_de_mexico/articulo/085775/ José Luis Luege, presidente del PAN en el DF aprobó la determinación de la Corte de Justicia del DF que suspendió el decreto de que el DF no se integre al Horario de Verano. (José Luis Luege, president of the PAN in Federal District, approved the determination of the Supreme Court of DF that suspends the decree which says that DF will not participate in the daylight saving). Pide PRI terminar confrontación AMLO-Fox (PRI party asks for the termination of the confrontation AMLO-Fox) http://www.reforma.com/ciudad_de_mexico/articulo/085777/ Jorge Schiaffino dirigente priísta en la Ciudad de México llamó al Jefe de Gobierno a dejar la confrontación con el Presidente Fox. (Jorge Schiaffino the leader of PRI in Mexico City, urged the Chief of Government to leave the confrontation with President Fox) We are still awaiting the final decision of the Supreme Court, which should probably be emitted within 15 days according to one of the articles. Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista 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 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://timezone50.homepage.com

1 0

Re: Updated Australian time zone names/strings
by Russ Allbery April 7, 2001

April 7, 2001

Greg Black <gjb(a)gbch.net> writes: > The broken software consists of real mail clients out there that people > are still using. Some of that software outputs email with dates in this > form: > Date: Thu, 21 Dec 2000 09:34:42 EST When used in e-mail, that Date header is not in the slightest bit ambiguous. RFC 822 requires as a matter of protocol that that time zone be interpreted as -0500. Section 5.1: zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM) Section 5.2: The other remaining two forms are taken from ANSI standard X3.51-1975. One allows explicit indication of the amount of offset from UT; the other uses common 3-character strings for indicating time zones in North America. RFC 822 further requires as a matter of protocol that only those 9 three-character abbreviations, the two-character abbreviation UT, and the single-character abbreviations A-Z (excluding J) be used as time zone abbreviations, and that all other time zones use an explicit time differential. Any software in Australian time zones that is generating e-mail Date headers with non-numeric time zones is broken and generating Date headers with no valid interpretation under a mail standard that is 19 (!) years old. I think it's about time that those mail clients get fixed, hmm? Furthermore, RFC 1123 states: There is a strong trend towards the use of numeric timezone indicators, and implementations SHOULD use numeric timezones instead of timezone names. However, all implementations MUST accept either notation. If timezone names are used, they MUST be exactly as defined in RFC-822. The military time zones are specified incorrectly in RFC-822: they count the wrong way from UT (the signs are reversed). As a result, military time zones in RFC-822 headers carry no information. so any software that is generating non-numeric time zones is violating a SHOULD in a mail standard that is now eleven and a half years old. > I can't force people who write to me (who are often people I don't know) > to replace their mail software just because I don't like the dates it > generates. However, if the TZ data gave the Australian users > unambiguous abbreviations for those zones, it would make life easier at > little or no cost to anyone. Except that per RFC 822, the "AEST" bit in a Date header like: Date: Thu, 21 Dec 2000 09:34:42 AEST has no actual meaning and can't be relied on to be anything at all. Given stuff like IST, if I were writing an e-mail client, I would interpret anything with a non-822 time zone as being in UTC and warn the user. Anything else just isn't worth it. Putting explicit tables into software to deal with e-mail clients written by people who haven't read *eleven-year-old* standards would just bug me far too much. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

2 1

Re: Updated Australian time zone names/strings
by Paul Eggert April 7, 2001

April 7, 2001

> Date: Thu, 5 Apr 2001 23:59:40 +1000 (EST) > From: David J N Begley <d.begley(a)uws.edu.au> > > since my last question everything has gone quiet: There has been some activity recently. Let me try to summarize my understanding of the discussion. I'm not Australian, so everything I write should be taken as comments by an interested outsider who does not entirely understand the situation there. I see the following points of dispute: * How important are unique time zone abbreviations? Here I tend to agree with the point (most recently made by Chris Newman) that unique abbreviations should not be essential for proper operation of software. We have other instances of ambiguity (e.g. "IST" denoting both "Israel Standard Time" and "Indian Standard Time"), and they are not likely to go away any time soon. In the old days, some software mistakenly relied on unique abbreviations, but this is becoming less true with time, and I don't think it's that important to cater to such software these days. On the other hand, there is another motivation for unambiguous abbreviations: it cuts down on human confusion. This is particularly true for Australia, where "EST" can mean one thing for time T and a different thing for time T plus 1 second. * Does the relevant legislation indicate which abbreviations should be used? Here I tend to think that things are a mess, just as they are in many other countries. We Americans are currently disagreeing about which abbreviation to use for the newly legislated Chamorro Standard Time, for example. Personally, I would prefer to use common practice; I would like to refer to legislation only for examples of common practice, or as a tiebreaker. * Do Australians more often use "Eastern Daylight Time" or "Eastern Summer Time"? Do they typically prefix the time zone names with the word "Australian"? My own impression is that both "Daylight Time" and "Summer Time" are common and are widely understood, but that "Summer Time" is more popular; and that the leading "A" is also common but is omitted more often than not. I just used AltaVista advanced search and got the following count of page hits: 1,103 "Eastern Summer Time" AND domain:au 971 "Australian Eastern Summer Time" AND domain:au 613 "Eastern Daylight Time" AND domain:au 127 "Australian Eastern Daylight Time" AND domain:au Here "Summer" seems quite a bit more popular than "Daylight", particularly when we know the time zone is Australian and not US, say. The "Australian" prefix seems to be popular for Eastern Summer Time, but unpopular for Eastern Daylight Time. For abbreviations, tools like AltaVista are less useful because of ambiguity. Many hits are not really time zones, unfortunately, and many hits denote US time zones and not Australian ones. But here are the hit counts anyway: 161,304 "EST" and domain:au 25,156 "EDT" and domain:au 18,263 "AEST" and domain:au 10,416 "AEDT" and domain:au 14,538 "CST" and domain:au 5,728 "CDT" and domain:au 176 "ACST" and domain:au 29 "ACDT" and domain:au 7,539 "WST" and domain:au 68 "AWST" and domain:au This data suggest that Australians tend to omit the "A" prefix in practice. The situation for "ST" versus "DT" is less clear, given the ambiguities involved. * How do Australians feel about the abbreviations in the tz database? If you just count Australians on this list, I count 2 in favor and 3 against. One of the "against" votes (David Keegel) counseled delay, saying that both AEST/AEDT and EST/EST are widely used and understood in Australia. > So, what happens now? The final decision is Arthur David Olson's, since he's maintaining the database. My own mild preference for now (given what's been said so far) would be to leave it alone.

4 8

RE: proposed tz patches for Mexico, Nunavut, Vostok, etc.
by Jesper Nørgaard April 7, 2001

April 7, 2001

* For what it's worth, I think that the AEST/AEDT suggestion for Australia is the most logical one to adopt. At present EST might mean Eastern Standard Time (in the US or Mexico), and Eastern Standard Time in Australia, and Eastern Summer Time in Australia, which makes it convenient to try to adopt a different and less redundant naming. Although as Paul Eggert points out there is not a consistent use of AEST/AEDT (e.g. by mail servers etc.) this seems to be the most used alternative acronym to EST/EST. I use AEST/AEDT already in my program World Time Explorer (Time Zone Converter). * A small spelling mistake: the reference to "Palabra" contains the date 2000-03-31, it should be 2001-03-31. Regards, Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Programador/Analista 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 CIMMYT home page: http://cimmyt.cgiar.org Check out my free program World Time Explorer: http://timezone50.homepage.com ---------- From: Paul Eggert[SMTP:eggert@twinsun.com] Sent: Sábado 31 de Marzo de 2001 21:37 To: tz(a)elsie.nci.nih.gov Subject: proposed tz patches for Mexico, Nunavut, Vostok, etc. Jesper Norgaard's letter about what actually happened in Mexico this morning prompted me to propose the tz patches enclosed below, which accumulate most of the changes recently proposed. The patches for Mexico are the most important, though Nunavut and Vostok also need fixes now so that current time stamps are reported correctly. Sorry, I haven't had time to think through the issue of Australian time zone abbreviations yet. If I recall correctly, we have so far: * one well-researched proposal to change from EST/EST etc to AEST/AEDT etc; * one second. * one dissenting vote to leave it at is. * my own brief research indicating that Australians themselves are not consistent Right now we have to get the Mexican patches out, so I'll leave the Australian abbreviations alone for now, but I'd like more votes and/or research if possible. Anyway, here is a summary of the patch proposed below: * Despite earlier predictions, America/Monterrey and America/Chihuahua did _not_ change their clocks today. They will change at the same time as the rest of Mexico. (Thanks to Jesper Norgaard for this.) * Nunavut went back to its pre-1999 ways, effective today. (Thanks to Rives McDow for this.) * Antarctica/Vostok is at UTC+6, not UTC+3. The message I got from Vostok was a bit confusing; perhaps nobody in Antarctica observes DST, contrary to our tables? We need more info about this. (Thanks to Lee Hotz for this.) * Correct several errors for Dutch daylight saving time before World War II. (Thanks to Robert H. van Gent for this.) * Alaska switched from Asian to American dates on 1867-10-18. We can't capture the Julian-to-Gregorian switch that occurred at the same time, but at least we can capture the 24-hour time zone change. (Thanks to Robert H. van Gent for this.) * The Philippines switched from American to Asian dates on 1844-12-31. (Thanks to Robert H. van Gent for obtaining a copy of the proclamation.) For now, guess the Ladrones switched at the same time. The following changes affect commentary only: * Add references to Vzic (a tz-to-VTIMEZONE compiler), and to possible XML schemata for tz data. * Add references to a history of the International Date Line, and to Netherlands time zone history. (Thanks to Robert H. van Gent for this.) * Update the status of various Antarctic stations, some of which have closed. * Update the instructions for running the XHTML validator. ... # James F. Smith writes in today's LA Times # </a> # * Sonora will continue to observe standard time. -# * Border states including Baja California, Chihuahua, and Nuevo Leon -# will use US rules, # * Last week Mexico City's mayor Andres Manuel Lopez Obrador decreed that # the Federal District will not adopt DST. # * 4 of 16 district leaders announced they'll ignore the decree. # * The decree does not affect federal-controlled facilities including # the airport, banks, hospitals, and schools. # -# For now we'll assume that the Federal District will bow to federal rules -# and that border states and Durango will stick with US rules. +# For now we'll assume that the Federal District will bow to federal rules. + +# From Jesper Norgaard (2001-04-01): +# I found some references to the Mexican application of daylight +# saving, which modifies what I had already sent you, stating earlier +# that a number of northern Mexican states would go on daylight +# saving. The modification reverts this to only cover Baja California +# (Norte), while all other states (except Sonora, who has no daylight +# saving all year) will follow the original decree of president +# Vicente Fox, starting daylight saving May 6, 2001 and ending +# September 30, 2001. +# References: "Diario de Monterrey" <www.diariodemonterrey.com/index.asp> +# Palabra <http://palabra.infosel.com/010331/primera/ppri3101.pdf> (2000-03-31) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mexico 1939 only - Feb 5 0:00 1:00 D @@ -1333,8 +1361,7 @@ Zone America/Merida -5:58:28 - LMT 1922 Zone America/Monterrey -6:41:16 - LMT 1921 Dec 31 23:18:44 -6:00 - CST 1988 -6:00 US C%sT 1989 - -6:00 Mexico C%sT 2001 - -6:00 US C%sT + -6:00 Mexico C%sT # Central Mexico Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 -7:00 - MST 1927 Jun 10 23:00 @@ -1353,8 +1380,7 @@ Zone America/Chihuahua -7:04:20 - LMT 19 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 - -7:00 Mexico M%sT 2001 - -7:00 US M%sT + -7:00 Mexico M%sT # Sonora Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 -7:00 - MST 1927 Jun 10 23:00 ...

2 1

Re: Updated Australian time zone names/strings
by Greg Black April 6, 2001

April 6, 2001

| The issue of the ambiguity of abbreviations like "EST" might best be solved | by prefixing the three initials with the ISO Country Code see | http://itl5.itlnet.com/isocodes.htm for examples. So the Australian EST | would be AUEST and the US EST would be USEST. Much as I want us to move away from EST/EST for Australia, I don't think too many people are going to welcome inventions when we have known and recognised existing practice in the form of AEST/AEDT. And I can't see anybody in the US getting excited about changing EST to USEST, no matter how pure it might look if we were actually starting with a clean sheet of paper.

1 0

RE: Updated Australian time zone names/strings
by rchapma6 ford.com April 6, 2001

April 6, 2001

Your cross posting caution was noted I similarly lurk on the ietf list and occasionally sally forth to pass comment. The issue of the ambiguity of abbreviations like "EST" might best be solved by prefixing the three initials with the ISO Country Code see http://itl5.itlnet.com/isocodes.htm for examples. So the Australian EST would be AUEST and the US EST would be USEST. There may be another advantage to do with Daylight Savings/Summer Time. These (I believe) are determined at national or regional level so those countries who do observe Daylight Savings/Summer Time would have two entries per time zone. for example:- USEST UTC -5:00 USEDT UTC -4:00 Add to this the entry and exit criteria for Daylight Savings/Summer Time (and I hope I get this correct!) USEST UTC -5:00 Last Sunday in September USEDT UTC -4:00 Last Sunday in March GBGMT UTC 0:00 Last Sunday in October GBBST UTC +1:00 4th Sunday in March?? or the explicit dates if there is no sensible way of determining when the clocks change! For countries like Japan where they do not observe Daylight Savings the entry would look like JPxxx UTC +8:00 The absence of date showing non-observation Hope that helps a bit Roger Chapman Specilaist, Collaborative Applications Ford Systems Integration Center Information Technology and eBusiness Ford Motor Company -----Original Message----- From: David Madeo [mailto:David.Madeo@morganstanley.com] Sent: 06 April 2001 05:21 To: Greg Black Cc: Paul Eggert; tz(a)elsie.nci.nih.gov; ietf-calendar(a)imc.org Subject: Re: Updated Australian time zone names/strings <Caution: cross posted to both ietf-calendar and tz mailgroups. Please reply carefully> Since I'm a lurker on both the tz and ietf lists, occasionally I see that it's appropriate to mix the audiences. This thread from the tz list is whether the tz maintainers should be trying to uniquify the timezone abbreviations such as "EST" which can mean several different timezones around the world, depending on whether you ask an Australian or an American. Greg Black wrote: > Paul Eggert wrote: > > | * How important are unique time zone abbreviations? > | > | Here I tend to agree with the point (most recently made by Chris > | Newman) that unique abbreviations should not be essential for proper > | operation of software. > > I think this flies in the face of common sense and the old > principle about being flexible in handling input while trying to > make output as good as possible. I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as unique names "Australia/Sydney" based on the Continent/Largest City. Anytime we can reduce confusion and make something easier for people *and* computers to understand, we should. > || The final decision is Arthur David Olson's, since he's maintaining > | the database. My own mild preference for now (given what's been said > | so far) would be to leave it alone. > > I know the decision is in Arthur David Olson's hands, but I > would imagine that he will be responsive to the wishes of the > affected parties. I'm keen to see more input into this. The tz database is the closest thing to a "standard" timezone listing. As such, there's a lot of benefit if it does the "right" thing. I've cc'd the ietf list since they are effectively "users" of this sort of data and might have some input. dmadeo

1 0