Time zone suggestions for draft-ietf-calsch-ical-08.txt
Here are some suggested improvements, in the area of time zones, to the latest iCalendar draft (which I got from: ftp://ftp.isi.edu/internet-drafts/draft-ietf-calsch-ical-08.txt ). * A more consistent naming strategy for TZIDs. The current draft is inconsistent: for the same time zone it sometimes says "America-New_York", sometimes "America-New York", and sometimes other things like "Eastern". TZIDs are arbitrary, but a good naming convention can help reduce the number of errors, ease maintenance, and improve interoperability. iCalendar should recommend, but not require, the names in the public-domain Olson database (omitting the names present there only for backwards compatibility); this is the best widely-available prior art. For NYC this name would be "America/New_York". * A reference to the Olson database prior art. Many potential implementers don't know about this useful source, and have thereby propagated incorrect time zone data. * Allow UTC offsets that are not multiples of one minute. This is needed for historically recent applications (e.g. the time zone in Liberia up to 1972). * The examples should be a tad more careful about distinguishing between US Eastern time and New York time, since there was a lot of confusion about the Eastern time zone before, say, 1976. Here's a proposed line-by-line patch to the -08 draft, which embodies these suggestions. --- draft-ietf-calsch-ical-08.txt Wed Jul 15 10:41:12 1998 +++ draft-ietf-calsch-ical-08.txt-fix Thu Jul 16 17:27:13 1998 @@ -1730,7 +1730,7 @@ The following are examples of this property parameter: - DTSTART;TZID=America-New_York:19980119T020000 + DTSTART;TZID=America/New_York:19980119T020000 @@ -1740,7 +1740,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTEND;TZID=America-New_York:19980119T030000 + DTEND;TZID=America/New_York:19980119T030000 The TZID property parameter MUST NOT be applied to DATE-TIME or TIME properties whose time values are specified in UTC. @@ -2031,7 +2031,7 @@ section on Time Zone. For example, the following represents 2 AM in New York on Janurary 19, 1998: - DTSTART;TZID=America-New_York:19980119T020000 + DTSTART;TZID=America/New_York:19980119T020000 Example: The following represents July 14, 1997, at 1:30 PM in New York City in each of the three time formats, using the "DTSTART" @@ -2039,7 +2039,7 @@ DTSTART:19970714T133000 ;Local time DTSTART:19970714T173000Z ;UTC time - DTSTART;TZID=America-NYC:19970714T133000 ;Local time and time + DTSTART;TZID=America/New_York:19970714T133000 ;Local time and time ; zone reference @@ -2462,7 +2462,7 @@ Here is an example of evaluating multiple BYxxx rule parts. - DTSTART;TZID=US-Eastern:19970105T083000 + DTSTART;TZID=America/New_York:19970105T083000 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; BYMINUTE=30 @@ -2683,7 +2683,7 @@ X-TIMEOFDAY:133000Z - X-TIMEOFDAY;TZID=America-New York:083000 + X-TIMEOFDAY;TZID=America/New_York:083000 4.3.13 URI @@ -2737,11 +2737,12 @@ utc-offset = time-numzone ;As defined above in time data type - time-numzone = ("+" / "-") time-hour time-minute + time-numzone = ("+" / "-") time-hour time-minute [time-second] Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The value of "-0000" is not - allowed. + UTC offsets (i.e., ahead of UTC). The values "-0000" and "-000000" + are not allowed. The time-second, if present, may not be 60; if + absent, it defaults to zero. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. @@ -2801,8 +2802,8 @@ Property names, parameter names and enumerated parameter values are case insensitive. For example, the property name "DUE" is the same as - "due" and "Due", DTSTART;TZID=Eastern:19980714T120000 is the same as - DtStart;TzID=Eastern:19980714T120000. + "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is the same as + DtStart;TzID=America/New_York:19980714T120000. 4.6 Calendar Components @@ -3270,8 +3271,8 @@ locations adjust their time by a fraction of an hour. Standard Time is also known as Winter Time. Daylight Saving Time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. The - following table shows the changes in time zone rules for the eastern - United States starting from 1967. Each line represents a description + following table shows the changes in time zone rules for New York City + starting from 1967. Each line represents a description or rule for a particular observance. Effective Observance Rule @@ -3368,11 +3369,22 @@ the time in question, and using the offset value from that observance. + [TZ] is an informal, public-domain collection of time zone + information, which is currently being maintained by volunteer + Internet participants, and is used in several operating systems. + This database contains current and historical time zone information + for a wide variety of locations around the globe; it provides a + time zone identifier for every unique time zone rule set in actual + use since 1970, with historical data going back to the introduction + of standard time. + The top-level properties in a "VTIMEZONE" calendar component are: The mandatory "TZID" property is a text value that uniquely identifies the VTIMZONE calendar component within the scope of an - iCalendar object. + iCalendar object. The name SHOULD should be the name of a time + zone in [TZ], and the other "VTIMEZONE" properties SHOULD define a + subset of the rules given in [TZ]. The optional "LAST-MODIFIED" property is a UTC value that specifies the date and time that this time zone definition was last updated. @@ -3392,7 +3404,7 @@ "TZOFFSETFROM" is combined with "DTSTART" to define the effective onset for the time zone sub-component definition. For example, the following represents the time at which the observance of Standard - Time took effect in Fall 1967 for the eastern United States: + Time took effect in Fall 1967 for New York City: DTSTART:19671029T020000 @@ -3445,8 +3457,8 @@ Example: The following are examples of the "VTIMEZONE" calendar component: - This is an example showing time zone information for the Eastern - United States using "RDATE" property. Note that this is only suitable + This is an example showing time zone information for New York City + using the "RDATE" property. Note that this is only suitable for a recurring event that starts on or later than April 6, 1997 at 03:00:00 EDT (i.e., the earliest effective transition date and time) and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid @@ -3455,7 +3467,7 @@ starting June 1, 1997, ending December 31, 1997. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19971026T020000 @@ -3481,16 +3493,16 @@ END:DAYLIGHT END:VTIMEZONE - This is a simple example showing the current time zone rules for the - Eastern United States using a RRULE recurrence pattern. Note that + This is a simple example showing the current time zone rules for + New York City using a RRULE recurrence pattern. Note that there is no effective end date to either of the Standard Time or Daylight Time rules. This information would be valid for a recurring event starting today and continuing indefinitely. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z - TZURL:http://zones.stds_r_us.net/tz/America-New_York + TZURL:http://zones.stds_r_us.net/tz/America/New_York BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 @@ -3507,12 +3519,12 @@ END:DAYLIGHT END:VTIMEZONE - This is an example showing a fictitious set of rules for the Eastern - United States, where the Daylight Time rule has an effective end date + This is an example showing a fictitious set of rules for New York City + where the Daylight Time rule has an effective end date (i.e., after that date, Daylight Time is no longer observed). BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 @@ -3538,13 +3550,13 @@ Internet Draft C&S Core Object Specification June 29, 1998 - This is an example showing a fictitious set of rules for the Eastern - United States, where the first Daylight Time rule has an effective + This is an example showing a fictitious set of rules for New York City, + where the first Daylight Time rule has an effective end date. There is a second Daylight Time rule that picks up where the other left off. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 @@ -4974,14 +4986,14 @@ Example: The following are examples of non-globally unique time zone identifiers: - TZID:America-New_York + TZID:America/New_York - TZID:California-Los_Angeles + TZID:America/Los_Angeles The following is an example of a globally unique time zone identifier: - TZID:/US-New_York-New_York + TZID:/America/New_York 4.8.3.2 Time Zone Name @@ -5139,7 +5151,7 @@ Example: The following is an example of this property: - TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles + TZURL:http://timezones.r.us.net/tz/America/Los_Angeles @@ -5867,7 +5879,7 @@ RDATE:19970714T123000Z - RDATE;TZID=US-EASTERN:19970714T083000 + RDATE;TZID=America/New_York:19970714T083000 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 19960404T010000Z/PT3H @@ -5938,11 +5950,11 @@ rrulparam = *(";" xparam) - Example: All examples assume the Eastern United States time zone. + Example: All examples assume New York City time. Daily for 10 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;COUNT=10 ==> (1997 9:00 AM EDT)September 2-11 @@ -5956,7 +5968,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2-30;October 1-25 @@ -5964,7 +5976,7 @@ Every other day - forever: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=2 ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; October 2,4,6...20,22,24 @@ -5973,14 +5985,14 @@ Every 10 days, 5 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID/America/New_York:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 Everyday in January, for 3 years: - DTSTART;TZID=America-New York:19980101T090000 + DTSTART;TZID=America/New_York:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or @@ -5992,7 +6004,7 @@ Weekly for 10 occurrences - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;COUNT=10 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 @@ -6000,7 +6012,7 @@ Weekly until December 24, 1997 - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 @@ -6009,7 +6021,7 @@ Every other week - forever: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 Dawson/Stenerson 97 Expires January 1999 @@ -6028,7 +6040,7 @@ Weekly on Tuesday and Thursday for 5 weeks: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH or RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH @@ -6038,7 +6050,7 @@ Every other week on Monday, Wednesday and Friday until December 24, 1997, but starting on Tuesday, September 2, 1997: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; BYDAY=MO,WE,FR ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October @@ -6048,14 +6060,14 @@ Every other week on Tuesday and Thursday, for 8 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 Monthly on the 1st Friday for ten occurrences: - DTSTART;TZID=America-New York:19970905T090000 + DTSTART;TZID=America/New_York:19970905T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 @@ -6065,7 +6077,7 @@ Monthly on the 1st Friday until December 24, 1997: - DTSTART;TZID=America-New York:19970905T090000 + DTSTART;TZID=America/New_York:19970905T090000 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 @@ -6083,7 +6095,7 @@ Every other month on the 1st and last Sunday of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970907T090000 + DTSTART;TZID=America/New_York:19970907T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU ==> (1997 9:00 AM EDT)September 7,28 @@ -6093,7 +6105,7 @@ Monthly on the second to last Monday of the month for 6 months: - DTSTART;TZID=America-New York:19970922T090000 + DTSTART;TZID=America/New_York:19970922T090000 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO ==> (1997 9:00 AM EDT)September 22;October 20 @@ -6102,7 +6114,7 @@ Monthly on the third to the last day of the month, forever: - DTSTART;TZID=America-New York:19970928T090000 + DTSTART;TZID=America/New_York:19970928T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 ==> (1997 9:00 AM EDT)September 28 @@ -6112,7 +6124,7 @@ Monthly on the 2nd and 15th of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 ==> (1997 9:00 AM EDT)September 2,15;October 2,15 @@ -6121,7 +6133,7 @@ Monthly on the first and last day of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970930T090000 + DTSTART;TZID=America/New_York:19970930T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 ==> (1997 9:00 AM EDT)September 30;October 1 @@ -6131,7 +6143,7 @@ Every 18 months on the 10th thru 15th of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970910T090000 + DTSTART;TZID=America/New_York:19970910T090000 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, 15 @@ -6148,7 +6160,7 @@ Every Tuesday, every other month: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU ==> (1997 9:00 AM EDT)September 2,9,16,23,30 @@ -6158,7 +6170,7 @@ Yearly in June and July for 10 occurrences: - DTSTART;TZID=America-New York:19970610T090000 + DTSTART;TZID=America/New_York:19970610T090000 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 ==> (1997 9:00 AM EDT)June 10;July 10 @@ -6171,7 +6183,7 @@ Every other year on January, February, and March for 10 occurrences: - DTSTART;TZID=America-New York:19970310T090000 + DTSTART;TZID=America/New_York:19970310T090000 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 ==> (1997 9:00 AM EST)March 10 @@ -6181,7 +6193,7 @@ Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - DTSTART;TZID=America-New York:19970101T090000 + DTSTART;TZID=America/New_York:19970101T090000 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 ==> (1997 9:00 AM EST)January 1 @@ -6194,7 +6206,7 @@ Every 20th Monday of the year, forever: - DTSTART;TZID=America-New York:19970519T090000 + DTSTART;TZID=America/New_York:19970519T090000 RRULE:FREQ=YEARLY;BYDAY=20MO @@ -6213,7 +6225,7 @@ Monday of week number 20 (where the default start of the week is Monday), forever: - DTSTART;TZID=America-New York:19970512T090000 + DTSTART;TZID=America/New_York:19970512T090000 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO ==> (1997 9:00 AM EDT)May 12 @@ -6223,7 +6235,7 @@ Every Thursday in March, forever: - DTSTART;TZID=America-New York:19970313T090000 + DTSTART;TZID=America/New_York:19970313T090000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH ==> (1997 9:00 AM EST)March 13,20,27 @@ -6233,7 +6245,7 @@ Every Thursday, but only during June, July, and August, forever: - DTSTART;TZID=America-New York:19970605T090000 + DTSTART;TZID=America/New_York:19970605T090000 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; @@ -6246,8 +6258,8 @@ Every Friday the 13th, forever: - DTSTART;TZID=America-New York:19970902T090000 - EXDATE;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 + EXDATE;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 ==> (1998 9:00 AM EST)February 13;March 13;November 13 @@ -6266,7 +6278,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTSTART;TZID=America-New York:19970913T090000 + DTSTART;TZID=America/New_York:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 ==> (1997 9:00 AM EDT)September 13;October 11 @@ -6278,7 +6290,7 @@ Every four years, the first Tuesday after a Monday in November, forever (U.S. Presidential Election day): - DTSTART;TZID=America-New York:19961105T090000 + DTSTART;TZID=America/New_York:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 5,6,7,8 @@ -6290,7 +6302,7 @@ The 3rd instance into the month of one of Tuesday, Wednesday or Thursday, for the next 3 months: - DTSTART;TZID=America-New York:19970904T090000 + DTSTART;TZID=America/New_York:19970904T090000 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 ==> (1997 9:00 AM EDT)September 4;October 7 @@ -6298,7 +6310,7 @@ The 2nd to last weekday of the month: - DTSTART;TZID=America-New York:19970929T090000 + DTSTART;TZID=America/New_York:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 ==> (1997 9:00 AM EDT)September 29 @@ -6308,14 +6320,14 @@ Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z ==> (September 2, 1997 EDT)09:00,12:00,15:00 Every 15 minutes for 6 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 @@ -6330,14 +6342,14 @@ Every hour and a half for 4 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 Every 20 minutes from 9:00 AM to 4:40 PM every day: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 or RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 @@ -6351,14 +6363,14 @@ An example where the days generated makes a difference because of WKST: - DTSTART;TZID=America-New York:19970805T090000 + DTSTART;TZID=America/New_York:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO ==> (1997 EDT)Aug 5,10,19,24 changing only WKST from MO to SU, yields different results... - DTSTART;TZID=America-New York:19970805T090000 + DTSTART;TZID=America/New_York:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU ==> (1997 EDT)August 5,17,19,31 @@ -6963,14 +6975,14 @@ The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. + calendar users in a group. A time zone specification for New York + City has been specified. BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTIMEZONE - TZID:Eastern US + TZID:America/New_York BEGIN:STANDARD DTSTART:19981025T020000 RDATE:19981025T020000 @@ -6997,8 +7009,8 @@ CLASS:PUBLIC CREATED:19980309T130000Z SUMMARY:XYZ Project Review - DTSTART;TZID=US-Eastern:19980312T083000 - DTEND;TZID=US-Eastern:19980312T093000 + DTSTART;TZID=America/New_York:19980312T083000 + DTEND;TZID=America/New_York:19980312T093000 LOCATION:1CP Conference Room 4350 END:VEVENT END:VCALENDAR @@ -7424,6 +7436,9 @@ [RFC 2279] "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. + + [TZ] Olson, A.D., et al, Time zone code and data, + ftp://elsie.nci.nih.gov/pub/, updated periodically. [VCARD] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt, September
* A more consistent naming strategy for TZIDs. The current draft is inconsistent: for the same time zone it sometimes says "America-New_York", sometimes "America-New York", and sometimes other things like "Eastern". TZIDs are arbitrary, but a good naming convention can help reduce the number of errors, ease maintenance, and improve interoperability.
What I'd really like to see is a separate document defining globally-scoped timezone names. That way, TZIDs don't have to be arbitrary. I would think that such a document would want to use a subset of the names in the Olsen database. e.g. "/US/Eastern"
* A reference to the Olson database prior art. Many potential implementers don't know about this useful source, and have thereby propagated incorrect time zone data.
I agree that this would be useful.
* Allow UTC offsets that are not multiples of one minute. This is needed for historically recent applications (e.g. the time zone in Liberia up to 1972).
* The examples should be a tad more careful about distinguishing between US Eastern time and New York time, since there was a lot of confusion about the Eastern time zone before, say, 1976.
These also seem appropriate. Keith
Keith, I assume you mean globally-scoped names together with their corresponding VTIMEZONE component? I think this is a really good idea as well, but it's a fairly signifigant undertaking. There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? I could be impelled into leading this effort, but I think we'll need to discuss the scope of this in Chicago. Pete.
-----Original Message-----
* A more consistent naming strategy for TZIDs. The current draft is inconsistent: for the same time zone it sometimes says "America-New_York", sometimes "America-New York", and sometimes other things like "Eastern". TZIDs are arbitrary, but a good naming convention can help reduce the number of errors, ease maintenance, and improve interoperability.
What I'd really like to see is a separate document defining globally-scoped timezone names. That way, TZIDs don't have to be arbitrary. I would think that such a document would want to use a subset of the names in the Olsen database. e.g. "/US/Eastern"
I assume you mean globally-scoped names together with their corresponding VTIMEZONE component?
Yes, that's what I had in mind. But just defining the format of the global timezone names themselves would be a useful first step. (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. This probably doesn't cover all timezones that one might want to define, but it's a start.) -Keith
From: Keith Moore <moore@cs.utk.edu> Date: Sat, 08 Aug 1998 17:49:54 -0400 (Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices. Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them. If the ``don't mess with success'' argument is not enough to convince you, then let me explain why the Olson names are the way they are; perhaps that will help. I originally tried using an /XX/yyy style naming convention when I was designing the naming scheme currently used by the Olson database, but I discovered several problems with /XXX/yyy: * Time zone rule boundaries are not well correlated with current political subdivisions. For example, it is tempting to use `/US/IN' for US Eastern Standard Time without DST, as is currently practiced in most of Indiana, but that is incorrect, since part of Indiana _does_ observe DST. * Indiana alone has hundreds of distinct time zone histories, only a few of which are in the Olson database due to its 1970 cutoff; as time goes on, more will need to be added to the Olson database. Even if we identified which subdivisions of Indiana would work for today's time zone histories (which would be a lot of work), the divisions would need to be further subdivided in the future, and this will cause compatibility problems. * The names and boundaries of political subdivisions change too often. Even if we were to come up with names that work today, they would soon become obsolete. It's more stable to choose names that depend as little as possible on politics. * Using political subdivisions injects politics into what should be a technical discussion. To some extent this is unavoidable, but it should be forestalled as much as possible by avoiding political subdivisions in the first place. For these reasons, I used a naming convention that does not try to identify the political boundaries of a time zone rule region. Instead, I used the name of the most populous single location within the region. This method is be less controversial, more stable, and more accurate than trying to name the entire region. This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change; and it survived the conflict between India and Pakistan in Kashmir without having to suffer an embargo (unlike Microsoft Windows, which unwisely put political boundaries into its database). It's not infallible; e.g. when Kuybyshev (the most populous city in Russian UTC+4) changed its name back to Samara, the database had to change its name too. But in practice the current Olson scheme has turned out to be more stable than any scheme based on political subdivisions.
From: Keith Moore <moore@cs.utk.edu> Date: Sat, 08 Aug 1998 17:49:54 -0400
(Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices.
Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them.
Actually, when I suggested that '/' be the introducer for global timezones, I had the Olsen database in mind, and have always assumed that we should start with a subset of that database. But if you're trying to define a standard for global timezone names, it makes sense to think carefully about them and see if you want to keep all of the Olsen timezone names. Some of them don't seem authoritative enough. The Olson database has the (to me) undesirable property that there are a lot of aliases. It seems like we would rather have "canonical" names when possible. And the Olsen database tries to define names for everything. It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. (like places that use solar time)
I originally tried using an /XX/yyy style naming convention when I was designing the naming scheme currently used by the Olson database, but I discovered several problems with /XXX/yyy:
* Time zone rule boundaries are not well correlated with current political subdivisions. For example, it is tempting to use `/US/IN' for US Eastern Standard Time without DST, as is currently practiced in most of Indiana, but that is incorrect, since part of Indiana _does_ observe DST.
I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. (somewhere I have a map of Indiana with different counties shaded according to their timezones) So you clearly can't force everything into clean and easily rememberd political subdivisions - you have to deviate somewhere. I still think it's convenient if *most* of the timezones are easily remembered. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate)
* Indiana alone has hundreds of distinct time zone histories, only a few of which are in the Olson database due to its 1970 cutoff; as time goes on, more will need to be added to the Olson database. Even if we identified which subdivisions of Indiana would work for today's time zone histories (which would be a lot of work), the divisions would need to be further subdivided in the future, and this will cause compatibility problems.
How important is it for iCalendar timezones to work before 1998?
* The names and boundaries of political subdivisions change too often. Even if we were to come up with names that work today, they would soon become obsolete. It's more stable to choose names that depend as little as possible on politics.
* Using political subdivisions injects politics into what should be a technical discussion. To some extent this is unavoidable, but it should be forestalled as much as possible by avoiding political subdivisions in the first place.
Well, I suppose we could use long/lat coordinates :)
For these reasons, I used a naming convention that does not try to identify the political boundaries of a time zone rule region. Instead, I used the name of the most populous single location within the region. This method is be less controversial, more stable, and more accurate than trying to name the entire region.
Yes, but what defines a region, and how do people know what region they are in? (or for that matter, how do people know the most populous city in a region?) What timezone should I (in Knoxville, TN) use? Should I say /America/Cincinnati or /America/Atlanta or what? The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names.
This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change; and it survived the conflict between India and Pakistan in Kashmir without having to suffer an embargo (unlike Microsoft Windows, which unwisely put political boundaries into its database). It's not infallible; e.g. when Kuybyshev (the most populous city in Russian UTC+4) changed its name back to Samara, the database had to change its name too. But in practice the current Olson scheme has turned out to be more stable than any scheme based on political subdivisions.
No argument there, and yet it would be nice if the names were obvious and guessable. It also seems like whenever there is a political border, we *know* there is a timezone fault-line where if a timezone changes on one side it will change independently of whatever is on the other side. There are of course other fault-lines: borders change, new borders are created, etc., but we can't anticipate everything. Finally, I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". (Note that the Pakistan/India conflict wouldn't have caused a problem anyway, because there was not a dispute about the names of the regions - only the borders of those regions.) Anyway, as I said earlier, I would defer to those with more experience. Keith
From: Keith Moore <moore@cs.utk.edu> Date: Sat, 08 Aug 1998 22:16:01 -0400 The Olson database has the (to me) undesirable property that there are a lot of aliases. Those aliases are mostly the result of the transition of old-style Olson names (e.g. US/Pacific) to the new-style names (e.g. America/Los_Angeles). Any new standard could omit the old-style names; this would alleviate the problem of aliases. Some of those old names are popular, though.... It might be better to not define timezone names where we don't have really good solid authoritative information, or where the local model of calendar doesn't quite fit with what iCalendar does. If we insist on ``really good solid authoritative information'', then I'm afraid coverage will be limited. Nobody keeps track of this stuff authoritatively on a world-wide basis. Nobody even keeps track of it authoritatively for Indiana! People have called for official bodies to keep track of this stuff authoritatively -- the ISO, or the UN, or the IATA, or somebody. It hasn't happened, and I don't think it likely to happen soon. (like places that use solar time) Nobody uses solar time any more for civil time. The last holdout was Saudi Arabia; they converted to UTC+3 in 1950. I believe Indiana actually has three different time zones: EST year round EST/EDT (near Cincinnati, OH) CST/CDT (near Louisville, KY) and this varies, as I understand, on a county-by-county basis. It's worse than that: the rules were not always uniform within the same county. (I don't see a problem with the different parts of Indiana using /US/Eastern, /US/Central, and /US/IN/no-dst, as appropriate) That doesn't work, because it mishandles time stamps before and after transitions. For example, Starke County, Indiana, switched from CST/CDT to EST on 1991-10-27 (according to the Washington Post that day). So Starke County needs its own unique time zone history. You can't just say that Starke County is EST, because that would mishandle time stamps before the switch; and you can't just say that Starke County is CST/CDT, as that would mishandle timestamps after the switch. How important is it for iCalendar timezones to work before 1998? iCalendar should be able to handle the problems that occurred before 1998, because it's likely that similar problems will occur after 1998. Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates? I suppose we could use long/lat coordinates :) That would work technically: e.g. instead of `/America/Los_Angeles' you would use `/+340308-1181434' (with ISO 6709 notation for latitude and longitude). I also considered that, but decided against it for a couple of reasons. First, it's unfriendly. Second, I was worried that people might argue about the coordinates (where _is_ the center of Los Angeles, exactly?). what defines a region, and how do people know what region they are in? Ideally, a region would be a maximal set of points all sharing the same time history. A time history would start when standard time was introduced, and would continue to the indefinite future. As time goes on, regions split and the number of regions grows. The Olson database deviates from this ideal by making two concessions to practicality. First, it looks only at time histories since 1970 when determining regions; this greatly reduces the number of regions (which would otherwise be in the thousands). Second, regions never cross current country boundaries; this is a concession to politics that I would have rather avoided from a theoretical point of view, but there were practical arguments for it (see below). Ideally, regions would appear on a map, and someone has actually done this for the Olson database; but I would urge that this not be made part of the standard, for political reasons as well as technical ones. Perhaps you could put the region boundaries into a non-normative annex or whatever the IETF calls that sort of thing. The most populous city within a region still would't suffice to define names for all of Indiana's timezone histories. Why not? There must be at least one location for each unique time history. Just pick the most populous one. Indiana has only 345 unique histories, according to Shanks (1990); each one has at least one town in it. I realize that there are places where /XX/city works better, (because everybody who is nearby stays in sync with that city's time) but there are also a lot of places in the states for which "Eastern" "Central" "Mountain" and "Pacific" are the obvious names. The obvious names don't work once you take into account the fact that cities can change time zones or time zone rules. This happened, for example, to Boise in 1974, to Anchorage in 1983, to Knox, IN in 1991, and to Cancun last year; we can be pretty sure that it will happen again soon to somebody. I wonder if the average J. Random Windows user, when asked to specify his timezone, really wants to name a city in another country, even if it is the largest city in his "region". This isn't a problem, since (as mentioned above) regions never cross current country boundaries in the Olson database.
Keith wrote:
How important is it for iCalendar timezones to work before 1998?
and Paul answered:
iCalendar should be able to handle the problems that occurred before 1998, because it's likely that similar problems will occur after 1998.
That is very true. In my eyes, that means that the naming scheme for timezones should be extensible. Right, Paul?
Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates?
Well, that is another point. In my eyes, we should be able to use the mechanisms described in iCalendar for any use, including in the past (and I hope it successed on this way). OTOH, the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. Or should we have two repositories? As you pointed out, my goal is to do an automatic tool that "tranforms" the files at Olson database (tzdata19XXa.tar.gz, not the ones produced by zic) to a database in iCal format (and to Microsoft Win32's format as well). Therefore, be this database served by an Internel protocol, or be it used internaly with proprietary tools is IMHO a personal choice. Antoine
Date: Mon, 10 Aug 1998 11:28:21 +0200 From: Antoine Leca <Antoine.Leca@renault.fr> the naming scheme for timezones should be extensible. Right, Paul? Yes. The number of time regions will increase with time.
Besides, iCalendar should work for dates before 1998; I'd want to use it that way myself. Why limit it to future dates?
the aim here is to do a world-wide repository about timezones suitable for Internet scheduling, and here I believe the past problems will be an additional weight with no useful properties. It might be reasonable for iCalendar to ignore transitions before, say, July 1998 when considering what regions to have in its world-wide repository. This would lower the number of regions considerably. But why bother? The existing tz data gets you back to 1970 for free. It should be slightly more work to start with July 1998 (because you'll have to coalesce regions, select canonical representatives, and so forth) than to start with January 1970 (which should be a simple data translation). Date: Mon, 10 Aug 1998 11:56:18 +0200 From: Antoine Leca <Antoine.Leca@renault.fr> "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. That's not a good example, as Europe/London and Europe/Lisbon are currently distinct. Their TZNAMEs differ: Europe/London uses `GMT/BST', whereas Europe/Lisbon uses `WET/WEST'. (Also, when the liberals return to power in Portugal, they may well switch the clocks forward again. :-) However, I agree with your main point: the number of regions will decrease if we drop Europe/Berlin, Europe/Rome, etc. and standardize on Europe/Paris. Would this be acceptable politically, though? As Keith Moore pointed out, J. Random Windows user in, say, Berlin might be a bit upset if he has to point his browser at Paris to set his time zone. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Can you estimate how much would be saved by going with a 1998 horizon versus a 1970 horizon? I don't think it would be all that much, but I don't know what the assumptions are.
Keith Moore <moore@cs.utk.edu> wrote on 1998-08-08:
(Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices.
I have only seen this short excerpt from your mail quoted by Paul on the tz list, so I don't know whether you already know that there exists a new ISO 3166-2 draft standard, which defines ISO alpha codes for regional subdivisions within countries (e.g., the states in US and the bundesländer in DE): ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes ISO/DIS 3166-2, Codes for the representation of names of countries and their subdivisions -- Part 2: Country subdivision code ISO/DIS 3166-3, Codes for the representation of names of countries and their subdivisions -- Part 3: Code for formerly used names of countries Paul Eggert replied on 1998-08-08:
Why not just stick with the names already in the Olson database, preceded by `/' if necessary for the new standard? The Olson names are widely used existing practice, and I don't see a technical reason to change them.
I agree that naming a time zone after the most populated city within that time zone is a very flexible and sound approach. The only thing that irritates me about the Olson/Eggert tz names is that they are all prefixed by the continent name, which I feel is redundant information. Is there really a good rationale why it has to be "Europe/Berlin" for the German time zone and not just "Berlin". I know that the tz database is structured into several per-continent files, but if we propose these names as a more widely used standard, does the tz source file name really have to be a part of it? If there is not a very good rationale for the continent part of the names used in the tz database and if they are only an implementation kludge for allowing to split the database into several smaller files, then I suggest we consider dropping the continent names quickly (which can certainly be done in some backwards compatible manner). Apart form this detail, the tz database names are certainly the best scheme for naming time zones that I have seen so far and, like Paul, I am very skeptical about inventing a new one based on political boundaries. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
Markus Kuhn wrote:
Keith Moore <moore@cs.utk.edu> wrote on 1998-08-08:
(Offhand, I'm thinking in terms of /XX or /XX/yyy where XX is the iso 3166 country code and yyy is a political subdivision within that country. In many cases just /XX suffices.
I don't know whether you already know that there exists a new ISO 3166-2 draft standard, which defines ISO alpha codes for regional subdivisions within countries (e.g., the states in US and the bundesländer in DE):
As Paul explained, this might be inappropriate. For example, the finest degree for Indiana according to ISO DIS 3166-2 is US-IN, and this does not accord with current practice. OTOH, there is Europe or the Western Indies... take a look below!
I agree that naming a time zone after the most populated city within that time zone is a very flexible and sound approach. The only thing that irritates me about the Olson/Eggert tz names is that they are all prefixed by the continent name, which I feel is redundant information. Is there really a good rationale why it has to be "Europe/Berlin" for the German time zone and not just "Berlin".
First, I should say that I see no reason to invent a new scheme: better to not always reinvent the wheel! Well, my problem is that, *in the view of the iCalendar protocol*, adding a different entry for each country may be an unnecessary burden. So I think that the CET (or MEZ) timezone ought to be named "/Paris" (or "/Berlin", if Berlin is more populated than Paris), instead as the current count: Africa/Ceuta Arctic/Longyearbyen Europe/Amsterdam Europe/Andorra Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Budapest Europe/Copenhagen Europe/Gibraltar Europe/Ljubljana Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Monaco Europe/Oslo Europe/Paris Europe/Prague Europe/Rome Europe/San_Marino Europe/Sarajevo Europe/Skopje Europe/Stockholm Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Warsaw (currently questionable) Europe/Zagreb Europe/Zurich to a grand total of 31 entries! Please note that Keith pointed out the number of aliases in the tz database. Paul's answer lead me to think he understood it as the concept of "Link" that is here for backward compatibility reasons. But links are easy to skip; this is not the same game when one has to identify "Europe/London" and "Europe/Lisbon", that have very different history as timezones, but that are now equal, and also equal in the foreseable future. I believe that we should try to keep a minimum number of timezones, at least to not have to worry small implementations, and to keep the requirements on network traffic as small as possible. Antoine
From: "Pete O'Leary" <poleary@amplitude.com> Date: Sat, 8 Aug 1998 14:10:23 -0700 There is alot of information in the Olson work than needs to be converted into iCalendar VTIMEZONE format. From the looks of it, this could be done semi-automatically. Any takers? On July 16 Antoine Leca <Antoine.Leca@renault.fr> wrote that he is doing exactly that, though my impression was that he is doing it automatically, not semiautomatically. You might contact him to see what his current status is. It should be a simple matter of hacking the existing zic parser.
participants (5)
-
Antoine Leca -
Keith Moore -
Markus Kuhn -
Paul Eggert -
Pete O'Leary