- tz - lists.iana.org

time-zone-related comments on draft-ietf-calsch-csct-00.txt
by Paul Eggert Jan. 3, 1997

Jan. 3, 1997

Here are some comments on the time-zone-related parts of your Internet Draft ``MIME Calendaring and Scheduling Content Type'' <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-csct-00.txt> (November 1996). Please let me know if you have any questions about these comments, and I'd appreciate hearing about any updates to your draft. The comments below are similar to comments I've made about draft-ietf-calsch-sch-00.txt and draft-newman-datetime-00.txt, which I can forward if you're interested. 3.1.3.7 Date and Time The examples do not match the grammar in the use of the character `T' to separate date and time. The grammar specifies date followed by time; the examples use `T'. The grammar is to be preferred here. Common practice (allowed by ISO 8601) is to write the date followed by a space followed by time; this is easier for humans to read. ISO 8601 allows fractions to be preceded by `.' instead of `,'; this should be allowed by the grammar. The grammar allows a utc-offset without a sign; this should be fixed, as utc-offsets always have a sign in ISO 8601. Also, common practice (allowed by ISO 8601) is to omit the `:' and minutes of a UTC offset when minutes are zero. Here is a proposed patch: utc-offset = (_+_ / _-_) hour [[_:_] minute] Following the above suggestions, the examples can be expressed as follows in the extended notation: 1996-04-15 08:30:00-05 1996-04-15 13:30:00Z 3.1.5.2 Daylight Savings Rule 3.1.5.5 Time Zone The underlying model in these sections is too simplistic. It assumes that there is a ``standard time zone'' for the home calendar system, together with a single date and time for entering and exiting daylight saving time. However, locations sometimes alter the UTC offset of standard time (e.g. Portugal and Sri Lanka in 1996). Also, some locales have observed double daylight saving time for part of the summer (e.g. Britain in 1947), and two transitions do not suffice to represent this. The model should be fixed to allow an arbitrary sequence of UTC offset changes. If necessary, each change could be labeled by a daylight saving flag (to say whether the resulting time is considered to be ``daylight saving''), and a string label (e.g. `EST') that can be internationalized (e.g. to `HNE' for French-speakers in Montreal). I suggest that you consult the public domain time zone database maintained by Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated regularly) for ideas about how time zone and daylight saving information could be represented. For example, you could pass labels that identify time zone and daylight saving rules. In the Olson scheme, the label `America/Los_Angeles' identifies the complete UTC offset history for Los Angeles from to the introduction of standard time in 1883 to the indefinite future. The Olson database is updated as governments change the rules, so the label `America/Los_Angeles' can be used by application programs without worrying about the details. By the way, the proper term is ``daylight saving time'', not ``daylight savings time'' (at least, that is what the OED and the Random House Unabridged Dictionary prefer).

1 0

time-zone-related comments on draft-ietf-calsch-sch-00.txt
by Paul Eggert Jan. 3, 1997

Jan. 3, 1997

Here are some comments on the time-zone-related parts of your Internet Draft ``MIME application/calendar Content Type'' <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-sch-00.txt> (November 1996). Please let me know if you have any questions about these comments, and I'd appreciate hearing about any updates to your draft. The comments below are similar to comments I've made about draft-ietf-calsch-csct-00.txt and draft-newman-datetime-00.txt, which I can forward if you're interested. 3.2.3.19 TZID This section suggests that it is ``likely that we want an IANA registry of time zone/daylight rule names''. I suggest that you consult the public domain time zone database maintained by Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated regularly) for ideas about how such a registry should be maintained. The Olson scheme is an upward-compatible extension of the Posix TZ string representation for time zone and daylight saving rules. For example, in the Olson scheme, the label `America/Los_Angeles' identifies the complete UTC offset history for Los Angeles from to the introduction of standard time in 1883 to the indefinite future. The Olson database is updated as governments change the rules, so the label `America/Los_Angeles' can be used by application programs without worrying about the details. It should be easy to convert the Olson database to any proposed IANA registry of time zone and daylight saving info. Perhaps, as a first cut, you could start with the Olson database as the IANA registry. You might contact the mailing list tz(a)elsie.nci.nih.gov if you are interested in using their work. 3.2.3.20 TZBias 3.2.3.21 TZDstBias 3.2.3.22 TZStdBias 3.2.3.23 TZStdTrans 3.2.3.24 TZDstTrans 3.3.1.2 Definitions 3.3.1.4 Recurring Event Date and Time Specification The underlying model in these sections is too simplistic. It assumes that there is a ``standard time zone'' for the home calendar system, together with a single date and time for entering and exiting daylight saving time. However, locations sometimes alter the UTC offset of standard time (e.g. Portugal and Sri Lanka in 1996). Also, some locales have observed double daylight saving time for part of the summer (e.g. Britain in 1947), and TZStdBias does not suffice to represent this. The model should be fixed to allow an arbitrary sequence of UTC offset changes. If necessary, each change could be labeled by a daylight saving flag (to say whether the resulting time is considered to be ``daylight saving''), and a string label (e.g. `EST') that can be internationalized (e.g. to `HNE' for French-speakers in Montreal). This would be simpler and more accurate than the model in draft-ietf-calsch-sch-00.txt. I suggest that you consult the Olson database for ideas about how time zone and daylight saving information could be represented. 3.3.1.2 Definitions The proper term is ``daylight saving time'', not ``daylight savings time'' (at least, that is what the OED and the Random House Unabridged Dictionary prefer). ``Pacific Daylight Savings Time'' should be ``Pacific Daylight Time''. 3.3.1.4 Recurring Event Date and Time Specification This section does not address the problem of ``impossible times'' (e.g. `1996-04-07 02:30:00', which does not denote a valid local time in Los Angeles) or ``ambiguous times'' (e.g. `1996-10-27 01:30:00', which denotes two distinct valid local times in Los Angeles). When a time is converted from some locale to UTC, it may be found to be impossible or ambiguous; in that case, what should a scheduling application do?

1 0

time zone article
by Joe Celko [71062,1056] Jan. 1, 1997

Jan. 1, 1997

I am writing a book on data and databases. I need a short piece on timezones, UTC, leap seconds, etc. for the section on temporal data. If anyone has the time (pun) and would like to contribute, I can pay them a few bucks for their effort. I am more interested in getting the data than in getting a finished ready-to-publish article. Here is my biosketch by way of introduction: BIOSKETCH: Joe Celko is an Atlanta-based consultant with Northern Lights Software Ltd. and has been a member of the ANSI X3H2 Database Standards Committee since 1987 and helped write the ANSI/ISO SQL-89 and SQL-92 standards. Joe Celko has had several regular monthly or biweekly columns in the past eleven years in the computer trade and academic press. His current columns are: "SQL Explorer" in DBMS (Miller-Freeman), "WATCOM SQL Corner" in POWERBUILDER DEVELOPERS' JOURNAL (SysCon). Most recently, Mr. Celko also wrote: "Celko on SQL" in DATABASE PROGRAMMING & DESIGN (Miller-Freeman); "SQL Puzzle" in BOXES & ARROWS (Frank Sweet Publishing); "DBMS/Report" in SYSTEMS INTEGRATION (Cahner-Ziff); "Data Desk" in TECH SPECIALIST (R&D), "Data Points" in PC TECHNIQUES (Coriolis Group), "Celko on Software" in COMPUTING (VNC Publications, UK). and was editor for the "Puzzles & Problems" section of ABACUS (Springer-Verlag). Joe Celko is the author of four books on SQL: SQL FOR SMARTIES (Morgan-Kaufmann, 1995), INSTANT SQL (Wrox Press,1995), SQL PUZZLES & SOLUTIONS (Morgan-Kaufmann, 1997) and SECRETS OF THE SQL MASTER (Sys-Con, 1996). He is currently do a series under his name for Morgan-Kaufmann publishers. Joe Celko is a regular speaker and SQL instructor for Digital Consulting Inc., Norm DiNardi Enterprises, Boston University Corporate Education Center and Miller-Freeman Seminars. --CELKO--

1 0

Internet Profile for ISO 8601
by kuhn＠cs.purdue.edu Dec. 28, 1996

Dec. 28, 1996

You might be interested in reviewing the new Internet draft standard ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt which describes the future recommended Internet date and time notation for new applications. This standard describes a subset of ISO 8601 and recommended usage practice. For more information about ISO 8601, see also http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html The draft-newman-datetime-00.txt is still an early draft and could require some input from the date and time experts here. In addition, I also wanted to mention that all ITU-R TF Recommendations can now be ordered on-line from http://www.itu.int/itudoc/itu-r/rec/tf.html This includes for instance ITU-R TF.460-4, the standard that defines UTC. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

tzcode1996o.tar.gz and tzdata1996n.tar.gz
by ado Dec. 28, 1996

Dec. 28, 1996

The files ftp://elsie.nci.nih.gov/pub/tzcode1996o.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1996n.tar.gz are now available; these incorporate Paul Eggert's latest changes. --ado

1 0

Re: Timezone naming
by Janis.Papanagnou＠pc-plus.DE Dec. 27, 1996

Dec. 27, 1996

Markus wrote: > The time zone string CET or MET is never parsed by any software, because in > all applications (e-mail, news, etc.) the time format standards require > that a numeric local time - UTC offset is also provided (e.g., required by > RFC822 except for US names) and the numeric value is then used. Therefore, > MET->CET is no compatibility problem. That seems quite reasonable. A formal scheme is what I expect when handling time zones (myself or by application). > Consequently: Only humans have to recognize the time zone abbreviation > and it definitely does not make sense here to use one that does not > follow common practice (Langenscheid, PTB, SkyTV, CNN, etc.). That's the point, humans should be provided a user-friendly naming scheme. But I cannot second your conclusions. The US time zone "names" are very strange (to me!), but I don't care - it's not my domain, I have not to use them. CNN, etc. is not what I would call common practice; in DE I hear the terms MEZ (or MET). I am not talking with the PTB, nor do I inform myself by US broadcasts. Talking about i18n: are these TZ "names" really considered a matter of international standards ? Concerning computer variable TZ, I doubt it. Concerning the definition of an international standard, I do not think that the current 3-letter TZ "names" serve for i18n-"codes"; they are neither formal nor intuitive. As posted some weeks ago, ambiguities and coincidences happen to exist, too. The Olsen DB as a quasi-standard on computers shall fulfill demands of an IS ? To come back to the user-friendliness: the three letter "names" are easily misinterpreted (from a global view); I would prefer something intuitive. Janis

3 2

Australian time zoning
by Chris Carrier Dec. 24, 1996

Dec. 24, 1996

Alex Livingston writes: >>I was told recently that the town (district probably) of >>Kunumurra, in far north east Western Australia has switched its >>time zone to be the same as that of the Northern Territory >>instead of using WA time (they're just over the border, and the >>WA time zone is wildly inappropriate, so it makes sense). >To say that the WA time, 08:00 ahead of UT, in Kununurra (I presume that is >where is meant: there were no matches for Kunumurra on an AltaVista Web >search but about 200 for Kununurra [and 9 and 7 for Kunnunurra and Kununnurra >respectively]) is wildly inappropriate is more than an overstatement. The >WA-NT border runs along the 129 deg. E meridian, so WA time in Kunnunurra is >less than 36 minutes behind LMT. Is that particularly inappropriate? >If Kununurra adopts / has adopted NT time, 09:30 ahead of UT, then its time >will be / is more than 54 minutes ahead of LMT. Isn't that even more >"inappropriate"? It is Australia's "Central Time" (09:30 ahead of UT) that is >inappropriate. The closest it comes to being "appropriate" is on SA's eastern >border with NSW, where it is still 6 minutes ahead of LMT. According to Doane (1972) nt.au and sa.au adopted GMT+9 when they first adopted standard time 1895-02-01, and then moved to GMT+9:30 on 1899-05-01. Like many places, they moved from the right time to the wrong time. I believe that the change was made because Adelaide (138E35), the largest city in the two states/territories is right on the eastern edge of the time zone and prefers to be on LMT+0:16 to LMT-0:14. >IMHO Australia's time zoning is a farce. Australia is wholly responsible for >3 of world's "off the hour" time zones (central zone, Lord Howe Island and >Norfolk Island) and partially responsible for another 1 (Cocos Islands - same >time as Burma). While I would be opposed to current ACT if I lived there, I do not regard off- hour zones to be a bad thing, if it is a better fit to LMT. (ACT, of course, does NOT meet this standard.) If I lived in Portugal or Ireland, I would be in favor of GMT-0:30 instead of GMT or GMT-1. In the USA the row of states from North Dakota to Texas would be better off on GMT-6:30 instead of -6, especially since they all keep DST until late October. The least justifiable of these is "Central Time", and Lord Howe Island comes a close second, what with its almost entirely pointless daylight-saving practices. (I started a message about the latter several weeks ago but haven't got round to finishing it yet.): There seems to me to be two main options for the central zone: >1: Put the whole zone on UT+10 year-round (no more inappropriate than >Argentina, not to mention China), with the possible exception of the >southwest corner of SA (where hardly anyone lives), which could keep on UT+9 >(whether "officially" or otherwise) along with the southeast corner of WA >(where even fewer people live) which already keeps UT+8:45 year-round (ugh!). Actually if I lived in Kununurra I would want to keep UT+8:45 as opposed to either UT+8 (and certainly +9:30!). Given that LMT is probably about UT+8:35 (since the WA-NT border is +8:36), +8:45 is better than +8, +9, or +9:30. It would also be WA+0:45 and NT-0:45. >2: Put the whole zone on UT+9 during a standardised non-daylight-saving >period, advancing the southern section to UT+10 during a standardised >daylight-saving period. I like this idea better than idea 1.

1 0

No progress on EU eighth summertime directive
by peter＠aldie.co.uk Dec. 20, 1996

Dec. 20, 1996

There still doesn't appear to be much action on getting the next (eighth) EC Directive on summertime arrangements finalised. My contact in the EC Information Office in Edinburgh produced the following response from Brussels in mid November: `Theoretically the proposal should be adopted by the end of the year. Nevertheless European Parliament having not adopted its opinion yet, we do not know if the Council will be able to adopt a common postion by this date. In this case the final adoption might be in early spring.' She also sent me some newspaper clippings from 29 Nov that said the European Parliament had `backed plans to have the European Union change to summertime on the same day to end the disruption caused when some states are out of phase with the rest'. As we are already in this state this can only be a reference to the French proposals to opt out of Summer Time altogether. I didn't think that the European Parliament had much role in adopting directives. I was going to point to the Commission's UK web pages at http://www.cec.org.uk for a page which explained the directive creation process but it seems to have vanished since I last looked. I am pretty sure that this directive is controlled by the EU transport ministers. They had a meeting on 12--13 December. They did not discuss the issue, or at least if they did it wasn't mentioned in the press release after the meeting, and they certainly didn't decide anything. The next (informal) meeting is on 31 Jan 97. The next formal meeting is on 11 Mar 97. Lots of diary publishers are probably getting worried. I hope that the EU isn't organising any sort of Millennium event. I would hope that even they would be embarrassed by missing that deadline. :-) Peter Ilieve peter(a)aldie.co.uk

1 0

Re: Probable change needed to the Aust zone files
by alex＠agsm.unsw.edu.au Dec. 20, 1996

Dec. 20, 1996

>I was told recently that the town (district probably) of >Kunumurra, in far north east Western Australia has switched its >time zone to be the same as that of the Northern Territory >instead of using WA time (they're just over the border, and the >WA time zone is wildly inappropriate, so it makes sense). To say that the WA time, 08:00 ahead of UT, in Kununurra (I presume that is where is meant: there were no matches for Kunumurra on an AltaVista Web search but about 200 for Kununurra [and 9 and 7 for Kunnunurra and Kununnurra respectively]) is wildly inappropriate is more than an overstatement. The WA-NT border runs along the 129 deg. E meridian, so WA time in Kunnunurra is less than 36 minutes behind LMT. Is that particularly inappropriate? If Kununurra adopts / has adopted NT time, 09:30 ahead of UT, then its time will be / is more than 54 minutes ahead of LMT. Isn't that even more "inappropriate"? It is Australia's "Central Time" (09:30 ahead of UT) that is inappropriate. The closest it comes to being "appropriate" is on SA's eastern border with NSW, where it is still 6 minutes ahead of LMT. IMHO Australia's time zoning is a farce. Australia is wholly responsible for 3 of world's "off the hour" time zones (central zone, Lord Howe Island and Norfolk Island) and partially responsible for another 1 (Cocos Islands - same time as Burma). The least justifiable of these is "Central Time", and Lord Howe Island comes a close second, what with its almost entirely pointless daylight-saving practices. (I started a message about the latter several weeks ago but haven't got round to finishing it yet.) There seems to me to be two main options for the central zone: 1: Put the whole zone on UT+10 year-round (no more inappropriate than Argentina, not to mention China), with the possible exception of the southwest corner of SA (where hardly anyone lives), which could keep on UT+9 (whether "officially" or otherwise) along with the southeast corner of WA (where even fewer people live) which already keeps UT+8:45 year-round (ugh!). 2: Put the whole zone on UT+9 during a standardised non-daylight-saving period, advancing the southern section to UT+10 during a standardised daylight-saving period. In either case, a section of northeast WA could consider adopting UT+9 year-round. What chance of this? _______________ Alex LIVINGSTON Macintosh Support Computing & IT (C&IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) Sydney NSW 2052 AUSTRALIA E-mail : alex(a)agsm.unsw.edu.au; cit(a)agsm.unsw.edu.au (C&IT) Facsimile: +61 2 9313-7279 Telephone: +61 2 9931-9264

1 0

Probable change needed to the Aust zone files
by Robert Elz Dec. 18, 1996

Dec. 18, 1996

This is pretty minor, and may not be worth bothering with, but we do try to cover everything, so ... I was told recently that the town (district probably) of Kunumurra, in far north east Western Australia has switched its time zone to be the same as that of the Northern Territory instead of using WA time (they're just over the border, and the WA time zone is wildly inappropriate, so it makes sense). I hope to check this if I can find someone to check it with, and see if I can discover when it happened exactly. I wouldn't be in any great hurry to get this fixed, this is going to be one small town, and I would doubt very much that anyone there is running the tz code in any form... kre

1 0