June 1997 - tz - lists.iana.org

Re: ISO C strftime() extention for ISO 8601
by kuhn＠cs.purdue.edu 15 Sep '97

15 Sep '97

"Clive D.W. Feather" wrote on 1997-06-30 13:14 UTC: > You may be interested to know that WG14 adopted last week working paper > N733, which adds the following items to the strftime() function: > > %f is replaced by the weekday as a decimal number (1-7), where > Monday is 1 (the ISO 8601 weekday number). > %F is equivalent to "%Y-%m-%d" (the ISO 8601 date format). > %T is equivalent to "%H:%M:%S" (the ISO 8601 time format). > %V is replaced by the ISO 8601 week number of the year (weeks > begin on a Monday, and week 1 is the week that includes both > January 4th and the first Thursday of the year) as a decimal > number (00-53). Thanks a lot for forwarding this interesting working paper. Please forward the following comments to the authors of N733 and whoever else might be interested. If possible, I would like to review the final text of the new strftime() definition (will the current draft be on the Web somewhere?). Comments on WG14 proposal N733 ------------------------------ Markus Kuhn <kuhn(a)cs.purdue.edu> -- 1997-06-30 (= 1997-W27-1) I appreciate this proposal and I have the following related comments. a) The valid range for %V numbers is 01-53. There is no week 00 in the ISO 8601 week numbering scheme. The week before a week 01 is either week 52 or week 53 of the previous year. b) %V alone is not sufficient to be able to use the ISO week numbering system. Each week is associated with a year, the year in which the majority of the days of this week fall, and this is not necessarily the year in which all days of the weeks fall. For instance: The week 1999-W52 goes from 1999-12-27 to 2000-01-02, in other words, the day 2000-01-02 has a week notation of the form 1999-W52-7. There should be another format descriptor for the year to which the current ISO week belongs, preferably both in 4-digit (%G) and 2-digit (%g) form. If you implement an algorithm for %V, you'll get the value of %G anyway as a by-product very easily, and therefore it should be made available to the strftime() user. c) Existing practice: The Olson tzcode package <ftp://elsie.nci.nih.gov/pub/> contains a widely used strftime() implementation that supports already: %u ISO 8601 week day number (1 = Monday, 7=Sunday) %V ISO 8601 week number (01-53) %G ISO 8601 year of current week, 4-digits %g ISO 8601 year of current week, 2-digits Unless there is a good rationale for the characters suggested by N733, I would suggest to stick with %u instead of %f for the weekday number, and I hope that you will add %G and %g as used in the Olson package and Arnold Robbins' strftime version 3.0. Therefore, if I evaluate on 1977-01-02 the string %G-W%V-%u, I should get 1976-W53-7, and on 1975-12-29 I should get 1976-W01-1. Not directly related to N733, but affecting the same part of the standard, I have a number of other suggestions: d) The range for %S and tm_sec is currently defined to be 00-61 to provide for "as many as two leap seconds". This was based on a serious missunderstanding and there can never be two leap seconds per day as it becomes very obvious by reading ITU-R Recommendation TF.460-4 (I can send you a copy if you are interested). Since this 00-61 range is being widely quoted in other standards, this error should be fixed just to stop spreading this serious missconception of how leap seconds work. The correct range is 00-60. This is not an interoperability problem, but fixing this would make WG14 look like they know what they are doing, and it is therefore a good idea. e) I wonder whether %W is anywhere used and whether this field could be dropped to simplify implementation and memory cost. Countries that start the week with Monday normally use ISO 8601 week numbers (%V) and not the scheme defined by %W. I suspect %W was defined based on a missconception of how week numbers work in Europe. Unless anyone can come up with an example where %W is used or needed, I suggest to drop it as it looks completely useless to me (and please don't quote standards that just copied the %W from ISO C). f) In the definition of %y and %Y, the first two digits of a four digit year are refered to as the "century", which is problematic, since the years 1999 and 2000 belong to the 20th century, but 2001 belongs to the 21st century. Suggested better wording: "%y is replaced by the last two digits of the year as a decimal number (00-99)". Again, not a serious interoperability problem, but it makes WG14 look like they know what they are doing. g) mktime() is the inverse function of localtime(), but there exists no portable inverse function for gmtime() that converts a struct tm given in UTC into time_t. This is a serious problem, and the addition of a new function (e.g., mkgmtime() might be a possible name) should be considered seriously. It is not possible to invert gmtime() in a 100% portable way in an application program, and in practice, I have encountered awful hacks like binary searches over the time_t range to invert gmtime() in an as portable as possible way. See <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html> for further info. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

2 1

Hong Kong
by Garrett Wollman 30 Jun '97

30 Jun '97

Someone on the NTP newsgroup pointed out that China uses a single time zone for the entire country. Does anyone out there on this list know whether Hong Kong will be allowed to keep its current timezone after the takeover? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman(a)lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick

1 0

ISO 8601 and the horrible "T"
by Misha Wolf 27 Jun '97

27 Jun '97

Stu Weibel has given me permission to quote from his private mail: > Where you have YYYY-MM-DDThh:mm-hh:mm, is it possible to interpose a > seperator other than T that makes it clearer to the human eye where > the date ends and Time begins? I suspect the answer to this is that > such a separator would knock the profile out of whack with 8601, but > I thought I'd ask anyhow. The "T" is, I think, the most despised aspect of the ISO 8601 standard but I think we're stuck with it. Some relevant quotes from the standard: [T] is used as a time designator to indicate the start of the representation of the time of day in combined date and time of day expressions; The space character shall not be used in the representations. The only suggestion I have seen for getting rid of the "T" is a kind of trick: We say that we are representing not a "combined date and time" but rather a separate date and a time. We then place them next to each other, separated by our favourite character. If "*" represents our favourite character, we get: 1994-11-05*08:15:30-05:00 instead of: 1994-11-05T08:15:30-05:00 The problem with this solution is precisely that it is a trick. In reality, we are dealing with a single date-with-time and it confuses things to pretend that we're not. Also, there must be lots of software out there which is ISO 8601-conformant and would choke on our favourite character. I suggest we decide that this stuff isn't primarily for human consumption and make use of it, warts and all. ------------------------------------------------------------------------ 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

Atlantic Monthly coverage of 2000/2001
by ado 26 Jun '97

26 Jun '97

See http://www.theatlantic.com/issues/97jul/preview.htm for a very brief blurb on the magazine's article entitled "Zero" regarding when the millenium comes; see the magazine itself for details. Your correspondent was disappointed that there was no replay of the joke from Saul Bass's film "Why Man Creates:" First cartoon charcter: I've discovered the zero. Second cartoon character: What? First cartoon character: Nothing, nothing. --ado

1 0

Re: Draft profile of ISO 8601
by Misha Wolf 26 Jun '97

26 Jun '97

Pete Ciuffetti has given me permission to quote his private mail: > In your levels of granularity, what do you think about allowing year-only, > "YYYY" and year-month "YYYY-MM". This would help solve a need I perceive > in our database design at SilverPlatter. Most of our records are > bibliographic and they specify the date of publication for some described > item like a book or journal. Typically this is just a year, like "1997" or > it is a year and month, "Feb 1997", sometimes a day is specified. > > In my metadata, I'd like to store whatever granularity that makes sense for > the published item and I would like all the dates to conform to a standard. > But no standard seems to consider these broader levels of granularity. ISO 8601 does. I would be very happy to add these options to the profile. > Also, in these broad levels for comparison purposes, I suggest implied > values would be 01 for an unspecified month, and 01 for an unspecified day. For the moment, I have backed away from suggesting how dates of differing granularities be compared, as it is contentious. > Regards, > Pete Ciuffetti > SilverPlatter ------------------------------------------------------------------------ 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

Profile of ISO 8601 (draft) - RESEND
by Misha Wolf 26 Jun '97

26 Jun '97

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 26 Jun '97

26 Jun '97

> 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 25 Jun '97

25 Jun '97

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 24 Jun '97

24 Jun '97

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 24 Jun '97

24 Jun '97

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