- tz - lists.iana.org

Combination Session IERS Workshop
by iers＠hpvlbi.obspm.fr Sept. 9, 1998

Sept. 9, 1998

Subject : IERS Workshop in Potsdam : Last call for paper proposals for topic 2 (Combinations) Dear Colleagues Please find thereafter the tentative Combination Session agenda to be held on Wednesday 30 September: Topic 2: Combinations of Data for IERS Products; list of papers as of 9 September "Combination of Earth Orientation Series from Various Techniques" D. Gambis and E. Eisop "A Kalman-Filter-Based Approach to Combining Earth Orientation Series" Richard Gross "Contribution to the problem of combination of the data obtained by different techniques" Jan Vondrak "A combined series from length of day measurements: performance and analysis" L. I. Fernandez, E. F. Arias , D. Gambis "DORIS Orbit Determination Service (SOD)" J.P. Berthias, A. Guitart, S. Houry, A. Piuzzi "On unification and combination of SLR EOP series" Zinovy Malkin "New IGS Realization of ITRF and Simultaneous Combination of Station and EOP solutions" R. Ferland, J. Kouba, Y Mireault "Combination of VLBI, GPS and SLR data at the observation level" P.H. Andersen "Reference frame combination (of multi-techniques) at the level of processing" Sheng Zhu and Christoph Reigber "Russian VLBI for astronomy and geodesy: current status and prospects" Andrey Finkelstein Thank you for your eventual comments and suggestions concerning this agenda. Additional presentation proposals are still welcome. Abstracts should be send to : Daniel Gambis (gambis(a)obspm.fr) and Joachim Hoepfner (ho(a)gfz-potsdam.de) Thank you Best regards Daniel Gambis

1 0

Revision of ISO C 9x <time.h>
by Markus Kuhn Sept. 6, 1998

Sept. 6, 1998

The new ISO C draft is on <ftp://dkuug.dk/JTC1/SC22/wg14/index.html>. I think, the following message might be of great interest to many here. I hope Clive has in the meantime managed to join the tz list, such that we can discuss proposals here. Markus ------- Forwarded Message From: "Clive D.W. Feather" <clive(a)demon.net> Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in <time.h> as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new <time.h> section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - people will write full pieces of text for me to drop in as needed; - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> ------- End of Forwarded Message

5 10

latest time zone info
by David A. Coyle Sept. 2, 1998

Sept. 2, 1998

Hi: I'm subcontracting ona project at the USPS, and we need some reliable TimeZone info for the US. I have an FTP URL to your site, but it seems to be stale: is there a newer or otherwise more official source of time zone info? thanks, Dave Coyle Software Architect Tensor Information Systems Raleigh, NC

1 0

dls in Israel
by Rives McDow Sept. 2, 1998

Sept. 2, 1998

Dear Mr. Olsen, Here is an update on dls in Israel this year, both in an attached file and the text here. Sincerely, Rives McDow Wednesday, September 2, 1998 MK protests early end of daylight time MK Avraham Poraz (Meretz), who initiated the use of daylight time in Israel, has sharply criticized the Interior Ministry decision to end daylight time this Saturday at midnight. Poraz claimed that this year daylight time, which was supposed to end Oct. 17, has been shortened by 40 days. According to Poraz, its early end is a "blow to the majority of Israelis who want daylight time until the end of the summer." The Sept. 5 cutoff is intended to "serve the interests of a small minority of ultra-Orthodox Sephardic Jews who, during the [Hebrew] month of Elul, recite Slihot penitential prayers in the early morning hours and thus find daylight time inconvenient." This is another example of how Interior Minister Eli Suissa "favors the interests of a small minority at the expense of the interests of the majority," Poraz said. Suissa responded that although the law calls for a minimum 150 days of daylight time, this year it has been in force for 170. Regarding Poraz¹s claims about serving the interests of a minority, Suissa said that a committee that probed the entire issue and which generally confirmed the terms of the above law used professional criteria and did not take into consideration the "discomfort" of those who recite the Slihot prayers at this time of year. By Dalia Shehori, Ha¹aretz correspondent

1 0

RE: Possible Bug in INT_STRLEN_MAXIMUM macro
by Olson, Arthur David (NCI) Aug. 24, 1998

Aug. 24, 1998

-----Original Message----- From: Randy Thelen [SMTP:rthelen@netapp.com] Sent: Friday, August 21, 1998 7:17 PM To: tz(a)elsie.nci.nih.gov Cc: guy(a)netapp.com Subject: Possible Bug in INT_STRLEN_MAXIMUM macro The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. The bad news is that the macro definition indeed fails to match the comment; the good news is that the error results in over-generous sizing of arrays designed to hold ASCII representations of numbers. I've changed the "100" in the "#define" to the correct "1000"; the change will show up in the next version of tzcode. --ado

1 0

Revision of ISO C 9x <time.h>
by Markus Kuhn Aug. 22, 1998

Aug. 22, 1998

The new ISO C draft is on <ftp://dkuug.dk/JTC1/SC22/wg14/index.html>. I think, the following message might be of interest to many here: ------- Forwarded Message Date: Sat, 22 Aug 1998 21:00:08 +0100 To: David R Tribble <david.tribble(a)central.beasys.com>, Antoine.Leca(a)renault.fr, kuhn(a)cs.purdue.edu From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> Reply-To: "Clive D.W. Feather" <clive(a)demon.net> Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in <time.h> as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new <time.h> section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - - people will write full pieces of text for me to drop in as needed; - - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> Written on my laptop; please observe the Reply-To address ------- End of Forwarded Message

1 0

Possible Bug in INT_STRLEN_MAXIMUM macro
by Randy Thelen Aug. 21, 1998

Aug. 21, 1998

The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc.

1 0

Lat. / Long to timezone conversion
by O'Kelly, David Aug. 12, 1998

Aug. 12, 1998

To whom it may concern, I am currently trying to identify if there are any existing software products which can carry out a Latitude / Longitude conversion to the corresponding timezone. Initially I am concentrating on data for the U.S., Canada & Mexico and was wondering if any relevant or pertinent information may be available on this subject. Thank you for any help you can provide. - regards Dave David O'Kelly Principal Software Engineer Communications Division Logica Inc. tel + 1 415 288 5200 fax + 1 415 288 5299 email okellyd(a)logica.com

1 0

tzdata1998g.tar.gz
by Olson, Arthur David (NCI) Aug. 11, 1998

Aug. 11, 1998

The file ftp://elsie.nci.nih.gov/pub/tzdata1998g.tar.gz is now available; it incorporates the Lithuanian change provided by mgedmin(a)pub.osf.it; it also moves creation of the GMT link with Etc/GMT to "etcetera" (from "backward") to ensure that the GMT file is created even where folks don't want the "backward" links (as suggested by Paul Eggert). --ado

2 1

Time zone suggestions for draft-ietf-calsch-ical-08.txt
by Paul Eggert Aug. 10, 1998

Aug. 10, 1998

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

5 11