- tz - lists.iana.org

Profile of ISO 8601 (draft) - RESEND
by Misha Wolf June 26, 1997

June 26, 1997

Please accept my apologies if you have seen this message. I originally sent it over 24 hours ago but have not seen it reflected back. As I don't know where the problem lies, I've decided to resend the message. ------------------------------------------------------------------------ Introduction ============ This note defines a profile of [ISO 8601], the International Standard for the representation of dates and times. A discussion of [ISO 8601] is available at [KUHN]. [ISO 8601] describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements. The profile may be adopted by standards which require an unambiguous representation of dates and times. As different standards have their own requirements regarding granularity and flexibility, this profile offers a number of options. An adopting standard must specify which of these options it permits. Summary ======= This profile of [ISO 8601] defines four levels of granularity: 1. Date only 2. Date plus hours and minutes 3. Date plus hours, minutes and seconds 4. Date plus hours, minutes, seconds and decimal fractions of a second An adopting standard must permit one or more of these options. This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC, with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. An adopting standard must permit one or both of these options, unless the standard does not permit granularity options 2, 3 and 4. This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited"), unless the standard does not permit granularity option 4. The formats =========== 1. Date only ------------- The format is: YYYY-MM-DD Example: 1994-11-05 This example corresponds to November 5, 1994. 2. Date plus hours and minutes ------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mmZ Example: 1994-11-05T13:15Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm+hh:mm or: YYYY-MM-DDThh:mm-hh:mm Example: 1994-11-05T08:15-05:00 Both the examples in this section correspond to November 5, 1994, 8:15 am, US Eastern Standard Time. 3. Date plus hours, minutes and seconds ---------------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ssZ Example: 1994-11-05T13:15:30Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss+hh:mm or: YYYY-MM-DDThh:mm:ss-hh:mm Example: 1994-11-05T08:15:30-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 4. Date plus hours, minutes, seconds and decimal fractions of a second ----------------------------------------------------------------------- The number of seconds is followed by a dot and one or more digits representing a decimal fraction of a second. An adopting standard must specify both the minimum and the maximum number of digits, as described earlier. If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ss.sZ Example: 1994-11-05T13:15:30.45Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss.s+hh:mm or: YYYY-MM-DDThh:mm:ss.s-hh:mm Example: 1994-11-05T08:15:30.45-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30.45 am, US Eastern Standard Time. References ========== [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

RE: Draft profile of ISO 8601
by Olson, Arthur David June 26, 1997

June 26, 1997

> Treatment of missing elements: > In some cases, software components may need to compare a date/time using > coarser granularity with one using finer granularity. [One option:] The missing > portions are deemed to be equal to zero. This is the approach now taken in the time zone information files. --ado

1 0

Profile of ISO 8601 (draft)
by Misha Wolf June 25, 1997

June 25, 1997

Introduction ============ This note defines a profile of [ISO 8601], the International Standard for the representation of dates and times. A discussion of [ISO 8601] is available at [KUHN]. [ISO 8601] describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements. The profile may be adopted by standards which require an unambiguous representation of dates and times. As different standards have their own requirements regarding granularity and flexibility, this profile offers a number of options. An adopting standard must specify which of these options it permits. Summary ======= This profile of [ISO 8601] defines four levels of granularity: 1. Date only 2. Date plus hours and minutes 3. Date plus hours, minutes and seconds 4. Date plus hours, minutes, seconds and decimal fractions of a second An adopting standard must permit one or more of these options. This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC, with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. An adopting standard must permit one or both of these options, unless the standard does not permit granularity options 2, 3 and 4. This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited"), unless the standard does not permit granularity option 4. The formats =========== 1. Date only ------------- The format is: YYYY-MM-DD Example: 1994-11-05 This example corresponds to November 5, 1994. 2. Date plus hours and minutes ------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mmZ Example: 1994-11-05T13:15Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm+hh:mm or: YYYY-MM-DDThh:mm-hh:mm Example: 1994-11-05T08:15-05:00 Both the examples in this section correspond to November 5, 1994, 8:15 am, US Eastern Standard Time. 3. Date plus hours, minutes and seconds ---------------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ssZ Example: 1994-11-05T13:15:30Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss+hh:mm or: YYYY-MM-DDThh:mm:ss-hh:mm Example: 1994-11-05T08:15:30-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 4. Date plus hours, minutes, seconds and decimal fractions of a second ----------------------------------------------------------------------- The number of seconds is followed by a dot and one or more digits representing a decimal fraction of a second. An adopting standard must specify both the minimum and the maximum number of digits, as described earlier. If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ss.sZ Example: 1994-11-05T13:15:30.45Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss.s+hh:mm or: YYYY-MM-DDThh:mm:ss.s-hh:mm Example: 1994-11-05T08:15:30.45-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30.45 am, US Eastern Standard Time. References ========== [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

The Year 2000 Problem Listserv
by Monty Solomon June 25, 1997

June 25, 1997

Begin forwarded message: Date: Mon, 23 Jun 1997 23:16:12 -0700 From: Susan Evoy <sevoy(a)Sunnyside.COM> Subject: The Year 2000 Problem Listserv The Year 2000 problem is getting increasing attention and is a matter of growing concern in this country and abroad. There are forums for discussion of technical aspects of the problem but none that focus on the economic, social and political implications. If you would be interested in participating in a forum on the y2k (year two thousand) problem join the cpsr-2yk listserv! To subscribe to this list, you should send a message to listserv(a)cpsr.org In the body of the message, write: subscribe cpsr-y2k <firstname> <last name> Norman Kurland (kurlandn(a)crisny.org) will be the moderator of the list. Here is a possible opening question: What are the most critical economic, political and social consequences of the Year 2000 Problem? How should computer professionals be dealing with them? CPSR=Computer Professionals for Social Responsibility http://www.cpsr.org/dox/home.html cpsr(a)cpsr.org P.O. Box 717 Palo Alto, CA 94302 Phone: (415)322-3778 Fax: (415)322-4748

1 0

Re: Draft profile of ISO 8601
by Misha Wolf June 24, 1997

June 24, 1997

Dan Connolly wrote: > > Misha Wolf wrote: > > > 2. Date plus hours and minutes > > ------------------------------- > > > > The format is one of: YYYY-MM-DDThh:mmZ > > YYYY-MM-DDThh:mm+hh:mm > > YYYY-MM-DDThh:mm-hh:mm > > A major benefit of using YYYY-MM-DD over the Internet > traditional Tue, 30 Jan 1997... format is that string > comparisons work for date comparisons; e.g. you don't > have to go through heroics to sort log files by date. > > By including timezone stuff (+hh:mm), you lose that > benefit. > > Is there some motivation for including +yy:mm that > offsets this loss? [Note: For "+yy:mm" read "+hh:mm"] I'm not sure which of the following you are asking: Q1. Why have time zone info? Q2. Why not require that all dates/times be normalised to UTC when entered. Answer to Q1: A time is only meaningful within a time zone. Answers to Q2: a) I'm defining a profile with various options (this can be viewed as a family of profiles), such that each adopting standard can choose the appropriate options. For many purposes, the actual time zone is important. PICS, for instance, requires the time zone. b) The normalisation to UTC can easily be done prior to date/time collation/comparison. It involves just an addition or subtraction. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

Europe/Zurich
by Florian La Roche June 24, 1997

June 24, 1997

Why do you list Zurich for switzerland? (CH) The capital of the swiss is Bern. Thanks, Florian La Roche

1 0

Draft profile of ISO 8601
by Misha Wolf June 22, 1997

June 22, 1997

Though I have been reluctant to write a profile of [ISO 8601], the W3C HTML WG has decided it wants the spec for Cougar (the next version of HTML) to reference a date/time profile and I've been actioned to produce this profile by the end of next week. This note lists some preliminary thoughts for comment. If you want to find out more about [ISO 8601], visit [KUHN]. I wrote a few days ago that my goal is a profile which is: - conformant, - widely adopted, - easy to understand, - not too permissive, - not too restrictive, - electronically available. The way to reconcile some of these requirements is to provide a profile allowing several options, especially regarding granularity. Other standards could refer to the profile and state which option has/have been adopted. A rough sketch follows. I have borrowed some phrases from [KUHN]. Granularity =========== This profile of [ISO 8601] defines four levels of granularity: 1. Date only ------------- The format is: YYYY-MM-DD 2. Date plus hours and minutes ------------------------------- The format is one of: YYYY-MM-DDThh:mmZ YYYY-MM-DDThh:mm+hh:mm YYYY-MM-DDThh:mm-hh:mm where: Z indicates that the date/time uses Universal Time (UTC), +hh:mm indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC, -hh:mm indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. 3. Date plus hours, minutes and seconds ---------------------------------------- The format is one of: YYYY-MM-DDThh:mm:ssZ YYYY-MM-DDThh:mm:ss+hh:mm YYYY-MM-DDThh:mm:ss-hh:mm 4. Date plus hours, minutes, seconds and decimal fractions of seconds ---------------------------------------------------------------------- The format is one of those shown in option 3, with the insertion, immediately after "ss", of either a full stop or a comma, followed immediately by one or more digits representing a decimal fraction of a second, eg: YYYY-MM-DDThh:mm:ss.ddZ YYYY-MM-DDThh:mm:ss.dd+hh:mm YYYY-MM-DDThh:mm:ss.dd-hh:mm If adopting this granularity option, the adopting standard must state how many digits may be used to represent a decimal fraction of a second, eg: 2 digits, 1-3 digits, 1-99 digits, any number of digits. Treatment of missing elements ============================= In some cases, software components may need to compare a date/time using coarser granularity with one using finer granularity. This shall be done as described below. Granularity options 2-4 ----------------------- The missing portions are deemed to be equal to zero. Thus the following all represent the same date/time: 1997-06-20T12:34Z 1997-06-20T12:34:00Z 1997-06-20T12:34:00.00Z 1997-06-20T12:34:00.000000000000000000000000000Z Granularity option 1 -------------------- An isolated date is treated as if it had the following string appended: T12:00Z For example: 1997-06-20 is treated as if it were: 1997-06-20T12:00Z This approach, proposed by Charles Wicksteed, has the advantage that at 1997-06-20T12:00Z, most of the world would agree that the current date is 1997-06-20. Comments? ~~~ [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Date/time on the Internet
by Misha Wolf June 18, 1997

June 18, 1997

Increasing numbers of Internet-related protocols and standards need to reference dates/times in a standard manner. The base standard mostly used for this purpose is [ISO 8601]. This agreement on one base standard is a Good Thing. A note for folks working with dates where YYYY < 0000 or YYYY > 9999: I know ISO 8601 isn't right for you. You'll need to use another standard which fits your requirement. Sorry. ISO 8610 is a *very* permissive standard and so each Internet-related protocol/standard is making up its own profile of ISO 8601. That is a Bad Thing. Some of these are conformant profiles; others are not. And that's a Very Bad Thing. Some of the profiles are more restrictive; others are less so. An example of a non-conformant profile is that used by PICS 1.1 [REC-PICS-labels-961031]; see the extract below. This profile is non-conformant in that it separates the YYYY and MM and DD portions using the character "." instead of "-". The PICS profile is also surprisingly restrictive, in that it does not permit seconds to be included. An example of a conformant profile is that used by [draft-newman-datetime-01.txt]. This profile is also rather restrictive for some Internet-related protocols and standards, in that it mandates the use of hours, minutes and seconds. Some users may wish to specify only a date when creating metadata. Chris has agreed to make the time portion optional in his next draft. I would suggest we need a single profile which is: - conformant, - widely adopted, - easy to understand, - not too permissive, - not too restrictive, - electronically available. We also need to persuade the people specifying forthcoming standards such as PICS-NG, Cougar, etc, to use this profile. So, how do we proceed? Chris Newman's Internet Draft has two further disadvantages: (i) it's an Internet Draft (rather than an RFC) and (ii) it is made rather large and intimidating by catering for dates/times in the future and the associated mish-mash (did I spell that right?) of time zones. One possibility would be for Chris, who is currently busy on other important stuff, to find the time to split his Internet Draft into two: (i) a quickie covering just a profile of ISO 8601 and (ii) another, covering the more complex stuff. Another possibility would be for someone else to do the job (I'm not volunteering). Comments? A note on distribution: I have not found a single suitable forum for this topic, so I suggest it be discussed on the open lists (meta2(a)mrrl.lut.ac.uk) and (www-html(a)w3.org) and request that you send your responses to those two lists. I'll forward this initial message to a few other relevant lists, mostly closed ones, to give people on those lists notice of this thread. REFERENCES: [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [REC-PICS-labels-961031] "PICS Label Distribution Label Syntax and Communication Protocols", Version 1.1, W3C Recommendation 31-October-96. [draft-newman-datetime-01.txt] "Date and Time on the Internet", Chris Newman, Internet Draft, January 1997. An extract from [REC-PICS-labels-961031] follows: quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"' based on the ISO 8601:1988 date and time standard, restricted to the specific form described here: YYYY :: four-digit year MM :: two-digit month (01=January, etc.) DD :: two-digit day of month (01 through 31) hh :: two digits of hour (00 through 23) (am/pm NOT allowed) mm :: two digits of minute (00 through 60) S :: sign of time zone offset from UTC ('+' or '-') tz :: four digit amount of offset from UTC (e.g., 1512 means 15 hours and 12 minutes) For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date denoting November 5, 1994, 8:15 am, US Eastern Standard Time Note: The ISO standard allows considerably greater flexibility than that described here. PICS requires precisely the syntax described here -- neither the time nor the time zone may be omitted, none of the alternate formats are permitted, and the punctuation must be as specified here. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

help
by Michael.Matschir＠zamg.ac.at June 11, 1997

June 11, 1997

1 0

Small patches for tzcode1997e.tar.gz
by Andreas Jaeger June 4, 1997

June 4, 1997

Hi, I've send the following mail already once to the list but neither get an reply nor find it in tzarchive. Let's give it another try. I've noticed that tzcode1997e has some prototype definitions that don't match the actual function headers. I've appended a patch for private.h and also for scheck.c (I think that both parameters should be the same) and hope you can use it. Thanks for a really good package. Cheers, Andreas diff -cr tzcode1997e/private.h tz/private.h *** tzcode1997e/private.h Sun May 4 00:52:23 1997 --- tz/private.h Wed May 21 16:56:12 1997 *************** *** 176,188 **** ** Private function declarations. */ char * icalloc P((int nelem, int elsize)); ! char * icatalloc P((char * old, const char * new)); ! char * icpyalloc P((const char * string)); ! char * imalloc P((int n)); ! void * irealloc P((void * pointer, int size)); ! void icfree P((char * pointer)); ! void ifree P((char * pointer)); ! char * scheck P((const char *string, char *format)); /* --- 176,188 ---- ** Private function declarations. */ char * icalloc P((int nelem, int elsize)); ! char * icatalloc P((char * const old, const char * const new)); ! char * icpyalloc P((const char * const string)); ! char * imalloc P((const int n)); ! void * irealloc P((void * const pointer, const int size)); ! void icfree P((char * const pointer)); ! void ifree P((char * const pointer)); ! char * scheck P((const char * const string, const char * const format)); /* diff -cr tzcode1997e/scheck.c tz/scheck.c *** tzcode1997e/scheck.c Sun May 4 00:52:25 1997 --- tz/scheck.c Wed May 21 16:52:54 1997 *************** *** 11,17 **** char * scheck(string, format) const char * const string; ! char * const format; { register char * fbuf; register const char * fp; --- 11,17 ---- char * scheck(string, format) const char * const string; ! const char * const format; { register char * fbuf; register const char * fp; -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)alma.student.uni-kl.de http://www.student.uni-kl.de/~ajaeger/

1 0