January 1997 - tz - lists.iana.org

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

Jan. 2, 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. 2, 1997

Jan. 2, 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