- tz - lists.iana.org

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

spamming
by Sue Ann Bowling June 2, 1997

June 2, 1997

Is it possible to set up a filter such that only messages from outsiders and new list members (say for less than a month) be monitored? Sue Ann Bowling, Geophysical Institute, University of Alaska Fairbanks Professional URL http://climate.gi.alaska.edu/Bowling/Bowling.html Dog URL http://www.mcf.com/bowlingsite/dogpage.html

1 0

spam
by ado May 27, 1997

May 27, 1997

Right now the time zone list is handled on a UNIX system; mail sent to "tz" gets forwarded (as a result of an "/etc/aliases" entry) to the addresses that appear in a file maintained by hand. If anyone can recommend a filtering program to use in the /etc/aliases entry, I'd appreciate hearing from you by electronic mail to arthur_david_olson(a)nih.gov --ado

1 0

Re: Re: Answers to questions, spam problems
by Dave Skinner May 27, 1997

May 27, 1997

> > Dave Skinner writes: > > > I agree that the spammers should be stopped, and if that takes > > > monitoring postings before they are actually posted, then so be it. > > > Chris Carrier writes: > > The only posts that would be monitored/moderated would be those from > > non-tz subscribers; not an undue burden. > Dik Winters writes: > I do not believe that. Currently spammers are using throw-away accounts, > shortly they will be using throw-away subscribtions. Not to dwell on this subject for too long, but I tend to agree with Chris Carrier on this one, and I'm the one at the top of this sequence of quotes. I grew up where burglaries were rare, but did occur. So, we locked our doors when we left the house. By comparison, we had friends in rural Ohio who never locked their doors when they left the house; there was no need. Now, I live in one of the maze of cities and towns that make up the greater Los Angeles area, and there are many areas, that fortunately do not include the one in which I live, but which are nearby, that not only feel they need to lock their doors, but also the need to put bars on their own windows, which can really get in the way of the fire department should there be a fire. The point of this analogy is that letting subscriber articles through unmonitored is working for now as witnessed by Chris Carrier writes: > So the list moderator decided to require that all posts sent from non- > subscribers be cleared through him. Posts from subscribers are still > automatically posted. No spam has appeared on the list since this > policy was adopted five months ago. I would say we have been, up till now, operating like my friends in Ohio. At the point where we feel the spam has gotton bad enough, and I am not sure we are at that point yet, but if and when we get to that point, then we should do the equivalent of locking our doors, i.e. we probably should have non-subscriber articles be monitored. If that gets the job done, then we should leave our anti-spam security measures at that level. At a later time if the spammers start using "throw-away subscriptions" as Dik Winters fears, and if the spam again becomes a significant problem, then we should regretfully do the equivalent of adding the bars to our own windows as well. We can always take this more draconian precaution, but I really hate giving up freedoms, and adding work to the maintainers of this list, unless it really becomes necessary. We should not make the cure worse than the disease. Although I am switching analogies as I state the following, I really do not think we should have representatives of the post office, so to speak, censoring our mail simply to avoid that portion which is junk mail. Dave Skinner

1 0

Re: Answers to questions, spam problems
by Dik.Winter＠cwi.nl May 25, 1997

May 25, 1997

> >I totally agree that the spammers should be stopped, and if that takes > >monitoring postings before they are actually posted, then so be it. > > The only posts that would be monitored/moderated would be those from non-tz > subscribers; not an undue burden. I do not believe that. Currently spammers are using throw-away accounts, shortly they will be using throw-away subscribtions. dik

1 0

Answers to questions, spam problems
by Chris Carrier May 24, 1997

May 24, 1997

Joe Celko [71062.1056(a)compuserve.com] quotes me: >>... the growth of standard time laws. Don't remember much more about it, >>but the full story is in "The History of American Time." >Would you mind giving me the full reference for that book? Unfortunately I don't have a full reference. I remember it came out about 1990, and forget the author's name. It deals mostly with the establishment of standard time, with the last chapter devoted to daylight time. sharris(a)apple.com also quotes me: >Another, related mailing list I subscribe to, CALNDR-L, >run by Rick McCarty of East Carolina University, was suffering from spam >Can you tell me a bit about this list you are referring to, and how one can >subscribe? The list is about calendars: actual and proposed, along with related subjects, like the number of days in a year and the change in that number (which of course is related to leap seconds). It's been up since last October. To subscribe, send a one-line email SUBSCRIBE CALNDR-L to LISTSERV(a)ECUVM.CIS.ECU.EDU. In December members of CALNDR-L started to receive spam from various sources. So the list moderator decided to require that all posts sent from non- subscribers be cleared through him. Posts from subscribers are still automatically posted. No spam has appeared on the list since this policy was adopted five months ago. Although it is possible that a subscriber could send spam, anyone who did would be expelled from the list and everyone on the list is a sensible person who would not do such a thing. I would advocate a similar policy here on tz to stop spam. Dave Skinner (dave(a)kirdu.jpl.nasa.gov) wrote: >I totally agree that the spammers should be stopped, and if that takes >monitoring postings before they are actually posted, then so be it. The only posts that would be monitored/moderated would be those from non-tz subscribers; not an undue burden. Chris

1 0

Re: ["Matthias Urlichs" <smurf@work.smurf.noris.de>] POSIX vs "right" time difference
by Paul Eggert May 23, 1997

May 23, 1997

Date: Thu, 22 May 1997 15:06:40 +0200 (Funky) From: "Matthias Urlichs" <smurf(a)work.smurf.noris.de> the POSIX time zone files ignore leap seconds, i.e. are based on GMT, while the 'right' timezone take leap seconds into account. The base difference between those, according to "date", is 20 seconds (soon to be 21). That's wrong. The difference between UTC and TAI ("atomic time") is actually 30 (soon to be 31) seconds; the 10 seconds come from the fact that UTC and TAI were initially synchronized in 1958, and in 1972 it was realized that they've drifted apart... instant 10-second insertion. That's not what happened. There was no 10-second insertion in 1972. The atomic timekeepers didn't wake up from a 14-year sleep and notice that the world's clocks had drifted! Here's a more accurate description of what happened. Before 1972, UTC was adjusted continuously, without using leap seconds. At the moment of the POSIX Epoch (1970-01-01 00:00:00 UTC), UTC and TAI differed, not by an integral number of seconds, but by a fractional number. The difference between UTC and TAI did not become an integer until 1972, when the leap second regime was introduced. Therefore, it is impossible, on a system with integral time_t, to simultaneously support both "right" and POSIX times accurately before 1972. In some sense, the "right" approach yields undefined times before 1972, since the "right" approach assumes leap seconds. But we could attempt to extend the "right" approach by guessing what it would have been like had it existed. That is, with an integral time_t, we could _approximate_ "right" times before 1972 by consulting historical tables of the difference between UTC and TAI, and rounding to the nearest integer. This is unsatisfactory (not least because such tables understandably do not go back to times before atomic clocks were introduced!), but it is probably the best that we can do with the "right" approach assuming integral time_t. I view this improvement as a low-priority task since very few people use the "right" approach these days; the people who care about leap seconds are using other interfaces. Furthermore, the philosophy of the tz package is to describe times as they actually appeared at the time; it's hard to combine this with the notion of gedanken atomic clocks ticking away in, say, 1901.

1 0