- tz - lists.iana.org

Minute offsets
by Chris Carrier Jan. 17, 1997

Jan. 17, 1997

Markus G. Kuhn wrote: > I do not have very strong feelings about the optionality of the minute > offset, but my arguments for it are: > - only *very* few countries use it today and time zones are so often > redefined that there is some good hope that the 30-min offset zones > will disappear in 2020 or so. Then, we would not carry around > any more the obsolete minute fields in our headers. > - I personally think that the hour only offset is much more readable > and that the additional implementation effort (one single "if" in > my sample code) is so trivial that it is really not worth any > discussion. I would make minute offsets mandatory, because we are discussing not only contemporary but historical time zone data, when minute offsets were more common. Also IMHO minute offsets are not necessarily a Bad Thing; a small country without any of its territory going through an hourly meridian but with territory going through a minute offset might be better served by the minute offset zone; Portugal and Ireland, for example, fit GMT-0:30 closer than GMT or GMT-1. What I would favor is putting a colon in between hours and minutes, for readability; i.e. the time in Darwin, Australia is easier to read as GMT or UT+09:30 than as +0930. My $0.02 worth...

3 2

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Hi Ken, Hi Tom, Tom Peterson wrote: > > Since ISO C doesn't appear to present restrictions here and TOG says they > > don't support negative time_t's, perhaps this is an area where an industry > > precedent should be set. I've yet to see an errno defined for mktime() on > > other systems, but I don't see anything precluding it. Is this something we > > should consider adding to the tz code base? and Ken Pizzini answered: > > The question I have to ask here is: are we working on an ANSI/ISO C > standard compatible interface, or a POSIX/TOG based standard? If > the latter we can work with the understanding that time_t values > represent seconds since some epoch It's my understanding that the current TZ code request it. > and consider following TOG's > lead in saying that negative time_t values are not allowed. OTOH, I don't fell this is requested by the current code base. > But if we are working on something that trancends POSIX compliance > and should work on any standard C system then I don't feel that > we can reasonably rule out negative time_t values -- the C > standard allows far too many possible underlying semanatics > for time_t values. However, we can't aim at full C portability, since the code base made in *many* places the assumption that time_t is an integral type, counting seconds. And the C standard clearly states other implementations are possible. So, as you and Tom point out, we are "between two chairs". > > Is there an existing errno value/macro that > > would fit the description of "time is not representable"? > > The best existing one I see is ERANGE, but the explanitory text > on this system says "Result too large", so it isn't perfect. > (I feel that the description has a bug myself -- a range error > really does encompass more than just "too large" a result.) As the current standard says, this seems correct. ERANGE is used for signaling overflowing of mathematical operations. And the standard explicitly says that it *could* be used for signaling underflows, but doesn't enforce this behavior. If your system don't do it, "Result too large" seems a good description to me. I don't like the idea of re-using ERANGE, because mktime() can fail for others reasons than excessing the available values for time_t (one obvious example is a time in the autumn overloapping period with tm->tm_isdst==-1). I think a new constant is in order (I don't like the idea of a new signaling mechanism); what about EILTIME? Furthermore, since mktime can fail for different reasons (before Epoch, result too large, wrong DST setting, autumn indetermination, spring gap; others?), perhaps can we set up different constants? I also want to bring this discussion to <news:comp.std.c> as well, in part for bringing this to the attention of the members of the comittee in charge of C standardization, in part for asking the C gurus about the choice of an ESOMETHING constant(s). Amicalement, Antoine

1 0

Re: C Code for draft-newman-datetime-00.txt
by Antoine Leca Jan. 17, 1997

Jan. 17, 1997

Tom Peterson (USG) wrote: <from Ken Pizzini> > > A problematical situation on any implementation is distinguishing > > between an error return from mktime() and mktime() returning a > > legitimate -1 value. [...] > > An error code (or errno) would help here I think. If errno were set to a > particular value when mktime() really couldn't represent the value, we'd have > a way to distinguish between a valid -1 and and error -1 return value. I agree with you. > Problem is, we'd have trouble getting the standards like X/Open to accept > this, since they claim they don't support negative time_t's (ie: times before > the Epoch). Strictly speaking, mktime() is not a X/Open standard, but part of the standard C library. So IMHO, the solution lie more in the realm of ISO/JTC2/SC22/WG14 (the comittee in charge of C standardization) than in X/Open. And BTW, ISO C doesn't put any restriction on the range of the value of the time_t (which is only arithmetical, not necessary [un]signed long int); and Epoch does take any sense as long as ISO C is concerned. Best regards, Antoine

1 0

Re: Minute offsets
by ncm＠cantrip.org Jan. 17, 1997

Jan. 17, 1997

The argument that the time format must be obvious by example, so that idiots won't program it wrong, doesn't really apply any more. With the internet, it's easy to find the free code that implements the standard, and given correct free code, people too lazy to read the standard will also be too lazy to rewrite it. Nathan Myers ncm(a)cantrip.org

1 0

My comments on draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

Hello! I am the author of the ISO 8601 summary on http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html and I just found your new Internet draft ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt about a standard date and time notation for the Internet. I agree that such a standard would be very useful and hope to be able to assist you in finishing it. Here are some comments that I wrote down while reading your first draft: 1) You wonder, what standard defines UTC and leap seconds. This standard is ITU-R Recommendation TF.460-4. Using your credit card, you can now order very easily an electronic copy from the International Telecommunication Union Web server http://www.itu.int/itudoc/itu-r/rec/tf.html You'll find there also other related standards regarding UTC and time signal transmission. 2) You suggest in section 3 to implement a rule that assumes for the 2-digit years 50-99 that they belong to the 20th century. Considering that Unix systems cannot represent in time_t any point in time before 1970-01-01 00:00:00Z, and that there are not any electronic documents on the Internet with a timestamp predating 1970, I suggest that 70 is a more reasonable border date. Gives us 20 more years and I expect to be almost dead or at least retired by then. 3) In section 4, you recommend the offset -00:00 to indicate UTC. One might consider the much shorter "Z" notation specified by ISO 8601 for this very common case. Saves a few bytes and is consistent with international radio practice (Z = Zulu = UTC). In section 5.4, you do already allow "Z", so here the text is inconsistent. 4) In section 5.4, you allow the hour value 24. Both 00:00:00 and 24:00:00 are allowed by ISO 8601, but the notation 24:00 identifying the midnight at the end of the day is useful only for time interval notations (e.g., 20:00--24:00) and should not be used for unique timestamps. Better restrict the hour range to 00--23. Times like 24:00:01 definitely violate ISO 8601, but are supported by your grammar. 5) You use the ugly "T" separator between date and time. ISO 8601 supports also the notion of separate date and time fields, so I suggest you simply define your format to consist of a date and a time field separated by a space. This is the ISO 8601 notation used by GNU RCS for instance (see option -zLT). I personally feel that separating date and time field by a space increases human readability and is preferable over the ISO 8601 combined dateTtime field format. 6) In section 6, you suggest an IANA registry of time zone names. Forget this. ;-) Time zone rules and names are thanks to the creativity of our politicians MUCH to dynamic and unstable. For very good reasons, ISO 8601 does not use time zone abbreviations at all. An excellent Internet list of current and historic timezone names that is constantly updated is already available in form of the tz database. You definitely should have a look at this first. <URL:ftp://elsie.nci.nih.gov/pub/tz*>. In addition, your proposal does not use any time zone names (which is a good thing!). 7) You could add a reference to the technical corrigendum 1 for ISO 8601, which fixes a few typos in the standard. 8) You could make the minute part of the time zone optional and require that time zones with an integral number of hours offset to UTC (which are almost all!) should only be represented by a 2-digit offset. That is what GNU RCS does already and I think having only a single colon increases human readability. 9) Feel free to copy my arguments against the ancient 12h am/pm time format from <URL:http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, in order to help eradicate this silly notation from new software (for instance, sendmail still uses am/pm in Received: header lines, which I consider to be very bad Internet time practice). You should also not use the am/pm notation in section 5.5, as the am/pm notation is really a very US-specific idea. The rest of the world has used the 24h notation for many decades and other languages than English do not even have terms like am/pm. I highly recommend you to join the tz(a)elsie.nci.nih.gov mailing list, where you'll meet a number of very experienced Internet date, time, and especially timezone experts. Send e-mail to tz-request(a)elsie.nci.nih.gov to join the club and check ftp://elsie.nci.nih.gov/pub/tzarchive.gz for previous discussion. These are my suggestions for your draft. Please let me know when you have made any changes or have any questions. Thanks for your effort! Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

2 4

Re: C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

In message <32DD304D.40D(a)Renault.FR>, Antoine Leca wrote: > I didn't change anything, but this raises a point: wouldn't it be better > to pass a « time_t const *t » argument? > This is for consistency with other library functions, and portability > (particularly when time_t is a floating type). This rises an interesting question: Why does the C library functions always access time_t values by constant pointers and not by simply copying the value??? I never understood this part of the C lib API. How is portability increased by not using a call-by-value here? If there is any good reason that this has been done in libc, then I'd of course also add it to my code. I already did it for consistency with the existing library functions, but I'd like to know why this is supposed to be the right thing to do. > ¤ Comparing t with 0 doesn't take any sense (I know one system where > ¤ (time_t)0 is J2000,0, so negative t are allowed before 2000-01-01 12:00:00Z Ok, you are right. I just hope that the system you know does not encode 2000-01-01 11:59:59Z = (time_t) -1 as this value is reserved by the standard for error conditions. > ¤ Basically, you can't trust strftime to output what you want if you > ¤ don't set the locale to "C" before. > ¤ I know this code is overkill in the vast majority of cases. I just checked the standard again and it does not indicate that any of the conversion specifiers "%Y-%m-%d %H:%M:%S" depend on the locale. There ARE many conversion specifiers that depend on the locale, but not the above ones, so I understand that we do not have to switch to the "C" locale. > ****** 8601.c > if (prec > 0) { > sprintf(buf, ".%09ld", nsec); > buf += prec + 1; > ****** 8601wrt.c > if (prec > 0) { > int i=9; > while (i-->prec) nsec /= 10; > sprintf(buf, ".%0*ld", prec, nsec); > buf += prec + 1; > ****** > > ¤ I wrote this modification for avoiding a overflow of the buffer. > ¤ You may consider it as unnecessary (but you then may consider > ¤ issuing a warning in the man page). I checked already that nsec is not out of range previously, so I think this additional check is redundant. Thanks for your good comments and also for those I received from others. I'll post the next revision here soon. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

4 3

minor fixes for tzcode1996o
by Todd C. Miller Jan. 16, 1997

Jan. 16, 1997

This fixes potential buffer overflows, corrects getopt(3) usage (getopt(3) returns -1, not EOF these days), and adds another PCTS tweak to pass an arguably bogus test. The diff is reversed, sorry about that. - todd --- time/localtime.c Mon Jan 13 20:17:09 1997 +++ /home/millert/tmp/tzcode1996o/localtime.c Tue Nov 5 11:50:08 1996 @@ -291,10 +276,10 @@ if (name[0] == ':') ++name; doaccess = name[0] == '/'; if (!doaccess) { if ((p = TZDIR) == NULL) return -1; - if ((strlen(p) + strlen(name) + 2) >= sizeof fullname) + if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) return -1; (void) strcpy(fullname, p); (void) strcat(fullname, "/"); @@ -1379,14 +1364,7 @@ dir = tmcomp(&mytm, &yourtm); if (dir != 0) { if (bits-- < 0) -#ifdef PCTS - { - t += 2; - break; - } -#else return WRONG; -#endif if (bits < 0) --t; /* may be needed if new t is minimal */ else if (dir > 0) --- time/zdump.c Mon Jan 13 20:17:17 1997 +++ /home/millert/tmp/tzcode1996o/zdump.c Tue Nov 5 12:00:05 1996 @@ -224,7 +223,6 @@ show(argv[i], t, TRUE); tm = *localtime(&t); (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); - buf[(sizeof buf) - 1] = '\0'; for ( ; ; ) { if (cutoff != NULL && t >= cuttime) break; @@ -241,7 +239,6 @@ newtm = *localtime(&newt); (void) strncpy(buf, abbr(&newtm), (sizeof buf) - 1); - buf[(sizeof buf) - 1] = '\0'; } t = newt; tm = newtm; @@ -283,7 +280,6 @@ lotm = *localtime(&lot); (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); - loab[(sizeof loab) - 1] = '\0'; while ((hit - lot) >= 2) { t = lot / 2 + hit / 2; if (t <= lot) --- time/zic.c Wed Jan 15 16:41:36 1997 +++ /home/millert/tmp/tzcode1996o/zic.c Fri Dec 27 19:42:04 1996 @@ -478,7 +476,7 @@ (void) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT - 0 */ progname = argv[0]; - while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != -1) + while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF) switch (c) { default: usage();

1 0

Revised C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 16, 1997

Jan. 16, 1997

Here comes the revised version of my example ISO 8601 output routine. It includes almost all suggestions that I have received plus some more and I have added test calls that should print on all POSIX systems the following: Show time in various forms: Fri Feb 13 18:59:59 2009 2009-02-13 18:59:59-05 2009-02-13 18:59:59.012-05 2009-02-13 23:59:59Z 2009-02-13 23:59:59.012Z 2009-02-13 23:59:60.012Z 2009-02-13 18:59:60-05 2009-02-13 23:59:59+00 2009-02-14 05:14:59+05:15 2009-02-14 05:14:59.012345678+05:15 Show a DST switch (Central Europe, October 1996): 1996-10-26 23:30:00Z = 1996-10-27 01:30:00+02 1996-10-27 00:00:00Z = 1996-10-27 02:00:00+02 1996-10-27 00:30:00Z = 1996-10-27 02:30:00+02 1996-10-27 01:00:00Z = 1996-10-27 02:00:00+01 1996-10-27 01:30:00Z = 1996-10-27 02:30:00+01 1996-10-27 02:00:00Z = 1996-10-27 03:00:00+01 1996-10-27 02:30:00Z = 1996-10-27 03:30:00+01 Thanks for the many valuable suggestions. Since I know now finally, why localtime() uses call-by-reference, I feel very comfortable with breaking the consistency with this legacy interface. Do you see any other portability or elegance problems? Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu /* * Example implementation of the RFC xxxx profile of ISO 8601 * ASCII standard date and time representation in ANSI/ISO C. * * This implementation is only an informal appendix of RFC xxxx and not * part of the standard. This is an early draft version, do not use * this in products yet. * * Please send comments for improvement to * * Markus Kuhn <kuhn(a)cs.purdue.edu> * * Thanks for suggestions to: * * Chris Newman <Chris.Newman(a)innosoft.com> * Ken Pizzini <ken(a)spry.com> * Antoine Leca <Antoine.Leca(a)renault.fr> * * $Id: demo8601.c,v 1.1 1997-01-15 22:02:37-05 kuhn Exp $ */ #include <stdio.h> #include <stdlib.h> #include <time.h> /* * Create an ISO 8601 time string conforming to the RFC xxxx profile * * Input: * * t the time that will be written as returned by time() * utc if true, then UTC instead of local time will be shown * nsec nanoseconds since start of current second or 0 if unknown * prec number of digits (0..9) for decimal fractions of the * second (set to 0 if nsec is unknown) * * Output: * * s time string with strlen(buf) < 36 * * When time_t does not allow to encode leap seconds (like in POSIX), * you can use the value of second 59 in t and add 1000000000 to nsec * in order to represent a leap second. If input or libary errors * are detected, NULL will be returned, otherwise a pointer to the * output string. If buf is NULL, the time string will be written to * a local buffer. This function is not multithreading safe. * * Markus Kuhn <kuhn(a)cs.purdue.edu>, 1997 */ char * create_timestring(char *s, time_t t, int utc, long nsec, unsigned prec) { char *buf, buffer[36]; struct tm ltm, utm, *tmp; long offset; /* safety checks */ s = buf = (s == NULL) ? buffer : s; *buf = '\0'; if (nsec < 0 || nsec > 1999999999L) return NULL; if (prec > 9) prec = 9; /* convert time */ if ((tmp = gmtime(&t)) == NULL) return NULL; utm = ltm = *tmp; if (!utc) ltm = *localtime(&t); /* leap second handling */ if (nsec > 1000000000L) { ltm.tm_sec++; utm.tm_sec++; nsec -= 1000000000L; } /* basic format */ buf += strftime(buf, 20, "%Y-%m-%d %H:%M:%S", utc ? &utm : &ltm); if (prec > 0) { sprintf(buf, ".%09ld", nsec); buf += prec + 1; } /* time zone offset */ if (utc) { *(buf++) = 'Z'; *buf = '\0'; } else { /* we assume without check that the offset is less than 24 hours */ offset = ltm.tm_yday - utm.tm_yday; if (offset > 1) offset = -24; else if (offset < -1) offset = 24; else offset *= 24; offset += ltm.tm_hour - utm.tm_hour; offset *= 60; offset += ltm.tm_min - utm.tm_min; sprintf(buf, "%+03ld", offset / 60); /* hour offset */ buf += 3; if (offset < 0) offset = -offset; offset %= 60; if (offset != 0) sprintf(buf, ":%02ld", offset); /* minute offset */ } return s; } /* Some test code */ int main() { char buf[50]; time_t now; time_t last_dst_hour; int i; puts("Show time in various forms:\n"); now = 1234569599L; /* on POSIX this is 2009-02-13 23:59:59Z */ putenv("TZ=EST5"); puts(ctime(&now)); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 0, 0); puts(buf); create_timestring(buf, now, 1, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 1012345678, 3); puts(buf); /* leap */ create_timestring(buf, now, 0, 1012345678, 0); puts(buf); /* leap */ putenv("TZ=UTC0"); create_timestring(buf, now, 0, 0, 0); puts(buf); putenv("TZ=TST-5:15"); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 9); puts(buf); puts("\nShow a DST switch (Central Europe, October 1996):\n"); last_dst_hour = (((26L * 365) + 6 + 300) * 24) * 3600; putenv("TZ=CET-1CEST,M3.5.0/2,M10.5.0/3"); for (i = -1; i <= 5; i++) { printf("%s = ", create_timestring(NULL, last_dst_hour + i * 1800, 1, 0, 0)); puts(create_timestring(NULL, last_dst_hour + i * 1800, 0, 0, 0)); } return 0; }

1 0

C Code for draft-newman-datetime-00.txt
by kuhn＠cs.purdue.edu Jan. 15, 1997

Jan. 15, 1997

I have done a sample implementation of the draft-newman-datetime-00.txt ISO 8601 profile with the modifications suggested by Paul and myself already included. So far, this is only the write routine, the parser will follow later. Please scrutinize the code below such that it becomes highly portable and reliable ANSI/ISO C. I have some doubts whether this code will handle the local time form correctly during both DST switch hours. Does anyone know a nicer solution for determining the UTC offset of local time with portable library functions reliably? (May be, something like "utm.tm_isdst = ltm.tm_isdst" before mktime() is still necessary?) Well-engineered ISO C example code that can easily be included in new applications will certainly make the ISO 8601 profile RFC more popular and should definitely be added. I would also like to see new format specifiers in GNU date (and POSIX.2 date) that would allow me to easily generate the UTC offset fields. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu #include <stdio.h> #include <stdlib.h> #include <time.h> /* * Create an ISO 8601 time string conforming to the RFC xxxx profile * * Input: * * t the time that will be written as returned by clock() * utc if true, then UTC instead of local time will be shown * nsec nanoseconds since start of current second or 0 if unknown * prec number of digits (0..9) for decimal fractions of the * second (set to 0 if nsec is unknown) * * Output: * * buf time string with strlen(buf) < 36 * * When time_t does not allow to encode leap seconds (like in POSIX), * you can use the value of second 59 in t and add 1000000000 to nsec * in order to represent a leap second. If input or libary errors * are detected, buf will be set to be an empty string. This function * is not multithreading safe. * * Markus Kuhn <kuhn(a)cs.purdue.edu>, 1997-01-15 01:00:18-05, early draft */ void create_timestring(char *buf, time_t t, int utc, long nsec, int prec) { struct tm ltm, utm, *tmp; double off; long offset; /* safety checks */ if (buf == NULL) return; *buf = 0; if (t < 0 || nsec < 0 || nsec > 1999999999L) return; if (prec > 9) prec = 9; /* convert time */ if ((tmp = localtime(&t)) == NULL) utc = 1; /* fallback when library does not know local time */ else ltm = *tmp; if ((tmp = gmtime(&t)) == NULL) return; utm = *tmp; /* leap second */ if (nsec > 1000000000L) { ltm.tm_sec++; utm.tm_sec++; nsec -= 1000000000L; } /* basic format */ strftime(buf, 20, "%Y-%m-%d %H:%M:%S", utc ? &utm : &ltm); buf += 19; /* fractional seconds */ if (prec > 0) { sprintf(buf, ".%09ld", nsec); buf += prec + 1; } /* time zone offset */ if (utc) { *(buf++) = 'Z'; *buf = 0; } else { off = difftime(t, mktime(&utm)); if (off < -0.01) { *(buf++) = '-'; offset = -off + 0.5; } else { *(buf++) = '+'; offset = off + 0.5; } offset = (offset + 30) / 60; sprintf(buf, "%02ld", offset / 60); /* hour offset */ buf += 2; offset %= 60; if (offset) sprintf(buf, ":%02ld", offset); /* minute offset */ } return; } int main() { char buf[50]; time_t now; now = time(NULL); puts(ctime(&now)); create_timestring(buf, now, 0, 0, 0); puts(buf); create_timestring(buf, now, 0, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 0, 0); puts(buf); create_timestring(buf, now, 1, 12345678, 3); puts(buf); create_timestring(buf, now, 1, 1012345678, 3); puts(buf); create_timestring(buf, now, 0, 12345678, 9); puts(buf); return 0; }

2 1

Re: -00:00 on draft-newman-datetime-00.txt
by David Keegel Jan. 14, 1997

Jan. 14, 1997

To quote some previously private email (with permission): ] On Sun, 12 Jan 1997, David Keegel wrote: ] > Perhaps when ISO-8601 allows different formats (eg: +hh:mm, +hhmm, or +hh) ] > and RFC822 only allows one of these formats, then it would be appropriate ] > to choose the common format (eg: +hhmm). Chris Newman wrote: ] For the "Internet profile", I selected the +hh:mm form. ISO does allow ] the +hhmm form, but one reading of the spec would say only if all ] punctuation is omitted from the rest of the date time format. If all the ] punctuation is omitted, the format becomes basically unreadable. I agree omitting all punctuation would be a Bad Thing. So the question hinges on whether ISO-8601 says you can omit punctuation from the time- zone, without omitting punctuation from everything else. Would anyone on the tz list like to interpret ISO-8601 to answer this? __________________________________________________________________________ David Keegel <djk(a)cyber.com.au> http://www.cyber.com.au/ +61 3 9642-5997 Cybersource P/L: Unix Systems Administration and TCP/IP network management

1 0

[J. Wunsch: hey (fwd)]
by Garrett Wollman Jan. 13, 1997

Jan. 13, 1997

This is something of a security bug report, but the security problem is not necessarily a bug in the timezone code. However, I do think it's a bug that our code (which is not the very latest tzcode) will crash if the TZ variable is set to point to a non-TZ file. I can think of two ways to combat this: 1) Disallow selection of files containing `.' or starting with a leading `/' unless the name is the same as TZDEFAULT. 2) Use some of the tzh_reserved[] bytes for a magic number. (2) is more flexible, but still allows for a malicious user to cause a core dump. I prefer (1) and will probably implement that unless someone can provide a good reason not to. ------- start of forwarded message (RFC 934 encapsulation) ------- From: J Wunsch <j(a)ida.interface-business.de> To: wollman(a)freebsd.org Subject: hey (fwd) Date: Fri, 10 Jan 1997 12:28:15 +0100 (MET) Hi Garrett, can you deal in time with this problem? Otherwise, i'd look into it myself. - ----- Forwarded message from Adam Kubicki ----- Message-Id: <199701092155.WAA12271(a)innocence.interface-business.de> From: Adam Kubicki <mikee(a)solozzo.tele.pw.edu.pl> Subject: hey To: joerg_wunsch(a)interface-business.de Date: Thu, 09 Jan 1997 23:02:44 MET In-Reply-To: <199612171142.MAA11937(a)ida.interface-business.de>; from "J Wunsch" at Dec 17, 96 12:42 (noon) X-Mailer: Elm [revision: 112.2] hi, there is a bug in tzset() function. setting TZ environment variable to some file, you can cause program to dump core - variables read from this file are used as various offsets in settzname() thus you get sigsegv. Because suid programs dont dump core, its not so dangerous, but you can export TZ in telnet and force login to dump core. gettimeoftheday() in login.c is called after loging in, but before setuid(uid) so you will get login.core in you home directory. this core file will follow symlink allowing you to overwrite any file on system. And, setting TZ to /etc/master.passwd you will find whole master.passwd in core file (touch login.core first to fool default umask/owner core flags). I'be be glad to get a smart patch from you, as quick fix i disabled TZ in telnetd. - -adam - ----- End of forwarded message from Adam Kubicki ----- - -- J"org Wunsch Unix support engineer joerg_wunsch(a)interface-business.de http://www.interface-business.de/~j ------- end -------

3 4

comments on draft-newman-datetime-00.txt
by Paul Eggert Jan. 9, 1997

Jan. 9, 1997

I liked Markus Kuhn's comments on your Internet Draft ``Date and Time on the Internet'' <URL:ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt> (December 1996). I have the following further comments and suggestions, some of them echoing Kuhn, some providing more details. Please let me know if you have any questions about these comments, and I'd appreciate hearing about any updates to your draft. Section 2 This section should mention that all dates use the Gregorian calendar. Section 3 Section 3 suggests that 00-49 should map to 2000-2049, and that 50-99 should map to 1950-1999. This contradicts existing practice in one important set of implementations: the XPG4 standard says that 00-68 should map to 2000-2068, and 69-99 should map to 1969-1999. This accommodates nonnegative Posix timestamps which start at 1970-01-01 00:00:00 UTC (equivalent to 1969-12-31 in some time zones). Any suggestion for mapping 2-digit to 4-digit dates is bound to be controversial. Perhaps it would be best to remove this recommendation entirely. If you must suggest a range, the XPG4 range is a bit better than the range in the December draft, as it matches existing practice better (and it will give you another 19 years to upgrade your software...). The recommendation ``Three digit years MUST be interpreted by adding 1900'' seems to be designed only for interfacing to buggy software (e.g. software that uses C's tm_year value without changing it). It is also incompatible with ISO 8601, which uses 3-digit strings for day-of-year. I suggest removing this recommendation. Section 3 mentions ``two digit'' years and ``three digit'' years without making it clear that we are talking about lexical syntax, not numeric value. This should be clarified. For example, the string `0096' should denote the year 96, not 1996; otherwise there would be no way to specify the year 96. Section 4.1 A good reference for local time zone rules is the tz database maintained by Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated regularly). Section 4.2 When the local offset is unknown, the offset "-00:00" MAY be used to indicate that the time is in UTC and the local offset is unknown. This is worded a little confusingly -- could you please clarify? Is it common to have situations where UTC is known but local time isn't? Without more motivation, it's hard to see why this suggestion is needed. Section 4.3 An alternative would be to show a list of the timezone labels defined in [section XXX]. I'm not sure what is meant here. Surely by ``timezone label'' you do not mean commonly used strings like `EST', since such strings are ambiguous in practice. E.g. `EST' has one meaning in the US, another in Brazil, and yet another in Australia (where the meaning of `EST' also depends on whether it is winter or summer!). Also, there is controversy about what the time zone labels ought to be -- e.g. should Canadian Eastern Standard Time be called `EST' (English) or `HNE' (French)? If by ``timezone label'' you mean some other identifying label, then I suggest using the Posix TZ string as extended by the Olson package (again, see <URL:ftp://elsie.nci.nih.gov/pub/>). This is common practice, is widely used, and there are multiple implementations; e.g. the source code to another implementation of the client library for the Olson TZ extensions can be found in <URL:ftp://prep.ai.mit.edu/pub/gnu/glibc-1.09.1.tar.gz>. For example, the Olson TZ string `America/Los_Angeles' stands for local time in Los Angeles; the Posix TZ string `CST-8' stands for the time zone named `CST' that is always 8 hours ahead of UTC. The advantage of `America/Los_Angeles' is that it can work correctly for all times in the past (the tz database has entries back to 1883, when Los Angeles adopted standard time), and requires no user modification to work correctly in the future, as the tables can be updated automatically by administrators as needed. Section 5.4 time-hour's range should be 00-23, not 00-24. ISO 8601 allows 24 but people are sometimes confused by it, it makes sorting a bit trickier, and it provides no useful functionality in this context. time-second allows leap seconds (value 60), but many systems do not support leap seconds. (E.g. Posix requires that the host not support leap seconds in time_t values.) The RFC should recommend what to do on a system that lacks leap second support when it is given a time stamp containing a leap second. I suggest that such systems treat values >= 60 as 59.999... (the number of 9s after the decimal point being the maximum allowed by the host). time-secfrac should use "." for the decimal point, as this is more commonly used in computer applications. Usurping "," for the decimal point might cause problems in applications that use "," for other punctuation. ISO 8601 allows "." for decimal point. time-numzone should not require specification of minutes (and seconds) as they are normally zero. E.g. change it to: time-numzone = ("+" / "-") time-hour [":" time-minute] date-time should not require a "T" between the date and the time; it should allow a space as well. This is easier to read, is allowed by ISO 8601, and is common practice. ISO 8601 provides no way to represent years before the year 0000, or after the year 9999. This makes it difficult to represent timestamps in some historical applications. To fix this, you might extend the syntax for date-fullyear to: date-fullyear = ["-"] 4*DIGIT where the years are numbered ..., -0002, -0001, 0000, 0001, 0002, .... (Note that unlike the traditional Julian calendar, there is a year 0 in the modern Gregorian calendar.) Section 6 I don't know of any ``IANA Registry of Timezone Names''. But please see my comments on Section 4.3 above for more details about an existing registry that could be used as the basis of an IANA registry. Appendix A Why is this section needed? Appendix B I don't see why this section is needed, since this draft RFC doesn't care about the day of the week. But if you think it's needed, here's the canonical reference for Zeller's congruence (written in German): Chr. Zeller, Kalender-Formeln, Acta Mathematica, Vol. 9, Nov. 1886 And here is code that is derived directly from Zeller's paper and uses Zeller's notation. #include <stdio.h> /* Return day of week, with 0 meaning Saturday and 1 meaning Sunday. See Chr. Zeller, Kalender-Formeln, Acta Mathematica, Vol. 9, Nov. 1886. */ int zeller (int year, int month, int day) { int jan_or_feb = month < 3; int y = year - jan_or_feb; int J = y / 100; /* century number */ int K = y % 100; /* year number within the same */ int m = month + 12 * jan_or_feb; /* month number */ int q = day; /* day number in the month */ int h = (q + ((m + 1) * 26) / 10 + K + K/4 + J/4 - 2*J) % 7; /* weekday number (1 is Sunday) */ return h; } char *dayofweek[] = { "Saturday", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" }; int main () { int year, month, day; printf("Enter the year (0001-9999): "); scanf("%d", &year); printf("\nEnter the month (1-12): "); scanf("%d", &month); printf("\nEnter the day of the month (1-31): "); scanf("%d", &day); printf("The day of the week is: %s\n", dayofweek[zeller (year, month, day)]); return 0; }

5 10

Re: Precise date of Millenium
by Jamie Zawinski Jan. 8, 1997

Jan. 8, 1997

Eric Ulevik wrote: > > Otherwise, the argument is that there was no year zero > in the Julian calendar, and we should celebrate after 2000 years. > Thus 1 January 2001. But people forget that the Gregorian calendar > skipped a number of days, so this is wrong! > > So if you wish to be pedantic, please celebrate on 1 January 2001 > on the Julian calendar, which is 14 January 2001 Gregorian. Well that depends on what event you're celebrating! 2000 years since the first second (apex?) of the Julian calendar? 2000 years since the first second of the Gregorian calendar? (As reckoned in the Julian calendar? Weird, but I think that's what you described...) 2000 years since the Julian calendar was introduced? That's still some centuries away. 2000 years since Jesus was born? Nobody really knows, do they? But hey, any excuse for a party... -- Jamie Zawinski jwz(a)netscape.com http://www.netscape.com/people/jwz/

2 2

Re: Newfoundland double summer time
by Rich Wales Jan. 8, 1997

Jan. 8, 1997

Alex Livingston wrote: island of Newfoundland (-03:30/-01:30, if it's true that double summer time is used there), The island of Newfoundland used "double" daylight savings time only in 1988. They switched back to regular DST the following year. Rich Wales <richw(a)yank.kitchener.on.ca> http://yank.kitchener.on.ca/~richw/

1 0

Re: Australian time zoning
by alex＠agsm.unsw.edu.au Jan. 7, 1997

Jan. 7, 1997

>Alex Livingston writes: > >>>I was told recently that the town (district probably) of >>>Kunumurra, in far north east Western Australia has switched its >>>time zone to be the same as that of the Northern Territory >>>instead of using WA time (they're just over the border, and the >>>WA time zone is wildly inappropriate, so it makes sense). > >>To say that the WA time, 08:00 ahead of UT, in Kununurra (I presume that is >>where is meant: there were no matches for Kunumurra on an AltaVista Web >>search but about 200 for Kununurra [and 9 and 7 for Kunnunurra and Kununnurra >>respectively]) is wildly inappropriate is more than an overstatement. The >>WA-NT border runs along the 129 deg. E meridian, so WA time in Kunnunurra is >>less than 36 minutes behind LMT. Is that particularly inappropriate? > >>If Kununurra adopts / has adopted NT time, 09:30 ahead of UT, then its time >>will be / is more than 54 minutes ahead of LMT. Isn't that even more >>"inappropriate"? It is Australia's "Central Time" (09:30 ahead of UT) that is >>inappropriate. The closest it comes to being "appropriate" is on SA's eastern >>border with NSW, where it is still 6 minutes ahead of LMT. I need to confess an oversight here: In fact, the closest Australia's "Central Time" comes to being "appropriate" is at the easternmost point of the shire containing the mining town of Broken Hill (and not much else), namely Yancowinna, NSW, which abuts the SA border. This town is considerably closer to SA's largest capital and largest city (Adelaide) then NSW's (Sydney) and in the shire containing it "Central Time" is kept, along with SA's daylight saving changes. However, unless this shire is particularly huge (and I'm sure it isn't), even at this point "Central Time" is probably still a couple of minutes ahead of LMT. >According to Doane (1972) nt.au and sa.au adopted GMT+9 when they first >adopted standard time 1895-02-01, and then moved to GMT+9:30 on 1899-05-01. >Like many places, they moved from the right time to the wrong time. That concurs with what I have read in a South Australian Yearbook. >I believe that the change was made because Adelaide (138E35), the largest city >in the two states/territories is right on the eastern edge of the time zone >and prefers to be on LMT+0:16 to LMT-0:14. Maybe. Or it didn't want to be so far behind the eastern states (especially Melbourne). >>IMHO Australia's time zoning is a farce. Australia is wholly responsible for >>3 of world's "off the hour" time zones (central zone, Lord Howe Island and >>Norfolk Island) and partially responsible for another 1 (Cocos Islands - same >>time as Burma). > >While I would be opposed to current ACT if I lived there, I do not regard off- >hour zones to be a bad thing, if it is a better fit to LMT. (ACT, of course, >does NOT meet this standard.) If I lived in Portugal or Ireland, I would be >in favor of GMT-0:30 instead of GMT or GMT-1. In the USA the row of states >from North Dakota to Texas would be better off on GMT-6:30 instead of -6, >especially since they all keep DST until late October. Doesn't the practice of observing DST blow any pretended association between legal time and LMT completely out of the water anyway? If a whole-hour intervals between zones are small enough to adequately resolve legal time for all practical purposes in one part of the world, aren't they small enough in every part? I would rather see time zone boundaries moved than off-hour time zones used. I lived most of my life in South Australia, and it irritated me when I had to work out the time almost anywhere else in the world and I had to get that half hour in the right direction (for others it would have been a snap, I'm sure). Another advantage of whole-hour timezone differences is that live broadcasts could give "global" time calls in terms of minutes before or after the hour. Yet another is that it reduces the proliferation of different times kept simultaneously when daylight-saving time is observed (e.g. there are at present five different times in use on the Australian mainland alone, six if the time kept at the roadhouse just west of the WA-SA border [UT+08:45, 0:45 ahead of WA and 1:45 behind SA!] is counted; if whole-hour time zones were in use there would be no more than four). >>There seems to me to be two main options for the central zone: >> >>1: Put the whole zone on UT+10 year-round (no more inappropriate than >>Argentina, not to mention China), with the possible exception of the >>southwest corner of SA (where hardly anyone lives), which could keep on UT+9 ----> ----> shouldn't have been there ^^ >>(whether "officially" or otherwise) along with the southeast corner of WA >>(where even fewer people live) which already keeps UT+8:45 year-round (ugh!). >>2: Put the whole zone on UT+9 during a standardised non-daylight-saving >>period, advancing the southern section to UT+10 during a standardised >>daylight-saving period. A third main option I forgot when I wrote that is: 3: Put the whole zone on UT+10 during a standardised daylight-saving period, retarding the southern section to UT+9 during a standardised non-daylight-saving period (i.e., same as 2, but with northern section on UT+10 year-round instead of UT+9 year-round). In any of these cases consideration could be given to keeping UT+9 in eastern and northern parts of WA. _______________ Alex LIVINGSTON Macintosh Support Computing & IT (C&IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) Sydney NSW 2052 AUSTRALIA E-mail : alex(a)agsm.unsw.edu.au; cit(a)agsm.unsw.edu.au (C&IT) Facsimile: +61 2 9931-9349 Telephone: +61 2 9931-9264

1 0

Re: The year 0 AD
by alex＠agsm.unsw.edu.au Jan. 7, 1997

Jan. 7, 1997

Peter Hullah wrote: >I think that, if you re-read what Chris said, he is of the same opinion >as you - as are, probably, >most clear thinking people and we probably don't need it spelt out in >words of one syllable. I'm sorry to have let off steam in the wrong forum and bored many people (grovel). I don't doubt that Chris is of the same general opinion as me. I'm afraid it triggered me off and I got carried away. But I hope you don't object to the use of words of one syllable in any context ;-) . Happy New Year to you too (no sarcasm intended). Eric Ulevik wrote: >Otherwise, the argument is that there was no year zero >in the Julian calendar I can't resist hammering this point: There is no modern-day obvious inevitability for a "year zero" in any calendar, just as there is no "day 0" at the beginning of a month or "month 0" at the beginning of a year (and I could list any number of other examples from very different contexts). Talk of a "year zero" is a red herring (though not a malicious or deliberate one). It is to my mind condescending and supercilious to belittle ancient calendar designers by claiming they didn't have a "concept of zero" - they probably did in fact, but they didn't need it. Well, that had better be the last I say on this topic here! _______________ Alex LIVINGSTON Macintosh Support Computing & IT (C&IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) Sydney NSW 2052 AUSTRALIA E-mail : alex(a)agsm.unsw.edu.au; cit(a)agsm.unsw.edu.au (C&IT) Facsimile: +61 2 9931-9349 Telephone: +61 2 9931-9264

1 0

Re: Precise date of Millenium
by kuhn＠cs.purdue.edu Jan. 6, 1997

Jan. 6, 1997

In message <32D16CDA.424F(a)ozemail.com.au>, Eric Ulevik wrote: > The obvious time to celebrate is when the calendar rolls over: > January 1 2000. This is when most of the world will celebrate. > (It is also when some computer systems might have some problems). > > Otherwise, the argument is that there was no year zero > in the Julian calendar, and we should celebrate after 2000 years. > Thus 1 January 2001. But people forget that the Gregorian calendar > skipped a number of days, so this is wrong! > > So if you wish to be pedantic, please celebrate on 1 January 2001 > on the Julian calendar, which is 14 January 2001 Gregorian. This is one of the frequently discussed topics on the net these days (and has been over the past 10 years during which I have been watching). You can find dozens of these threads with <URL:http://www.dejanews.com/>. In many senses, the discussion is futile as various definitions of the century and its roll-over have their justification. At least for Germans, Chancelor Kohl (Ph.D. in history) has defined in some interviews that the next millenium will start at 2001-01-01 (in the context that the German Mark will be replaced by the Euro with the beginning of the next millenium, something that causes already MUCH more software engineering work than the year-2000 problem). The real question is not when some counting system rolls over, but when is the right time to party. And the most intelligent answer I have heard on this so far is of course to party on all occations: 2000-01-01, 2001-01-01, 2001-01-14, etc. Therefore, I see the job of time and calendar experts to flood the media with many weired suggestions of when the right time for a new-millenium-party might be, to maximize their number. COBOL reverse engineering experts will certainly party on 00-01-01, Unix system administrators will wait until their epoch overflows 2038-01-19 03:14:08Z (signed 32-bit int) or 2106-02-07 06:28:16Z (unsigned 32-bit int). BTW: Hasn't Arthur C. Clark's HAL its birthdate in a few days? Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

Re: The year 0 AD
by alex＠agsm.unsw.edu.au Jan. 6, 1997

Jan. 6, 1997

>"Markus G. Kuhn" > INTERNET:kuhn@cs.purdue.edu > >>ISO 8601 provides no way to represent years before the year 0000, or >>after the year 9999. This makes it difficult to represent timestamps >>in some historical applications. To fix this, you might extend the >>syntax for date-fullyear to: > >date-fullyear = ["-"] 4*DIGIT > >>where the years are numbered ..., -0002, -0001, 0000, 0001, 0002, .... >>(Note that unlike the traditional Julian calendar, there is a year 0 >>in the modern Gregorian calendar.) > >WRONG! Negative year numbers are not part of the Gregorian calendar. Still not quite right: *non-positive* numbers are not part of the Gregorian calendar. Which presents me an opportunity too hard to resist to scream something that I have never yet explicitly read anywhere on this discussion group or anywhere else on the Internet. Year numbers are *ordinal* (as opposed to cardinal - correct me if I've got this the wrong way round), i.e., like the day of the month (and the month of the year when written numerically), they indicate the "howmanyeth" year it is (I can't think how better to put it). AD 1 was the *1st* year (of the era). 1997 is the 1997th year. It follows that the *1st decade* comprised the years 1 to 10 *inclusive* (the 1st, 2nd, 3rd, ..., and 10th years); the *1st century* comprised the years 1 to 100 *inclusive*; the *1st millennium* comprised the years 1 to 1000 *inclusive*. And 2000 will be the 2000th year and hence the last year of the 200th decade, the 20th century, and the 2nd millennium. This is one virtually unchallengable way of explaining why the next century (and millennium) begins at the beginning of 2001 (and not 2000) - and pointing that out is the main reason I'm writing this (though I guess I'm preaching to the converted here). Unlike time of day, specifications of year, month, and day of the month (and dates in general) indicate a *period* of time, not an instant. It is 1997 for a whole year; it is 10 o'clock for no time at all. Dates are discrete, time of day is a continuum. Just as the days within a month (and the months within a year) are numbered starting at 1, so are the years of an era. Another illustration (in case it still hasn't sunk in): The second half of a 30-day month starts on the 16th; the second half of the year starts with the 7th month; and the second half of a century starts with the 51st year of that century (ignoring for the moment the fact that months and years are not equal in length etc., making the use of the word "half" here questionable). >There are two ways to number years before 1 AD, astronomical and historical. > >In historical dating, the year 1 AD is preceded by 1 BC, as there was no >concept of 0 in Western civilization when Exigius set up the Anno Domini year >count in AD 532. The BC era is anomalous only in that the years are counted from latest to earliest rather than earliest to latest. Whether or not there was a "concept of 0" back then is entirely irrelevant. (I'm sure that in fact there already was something akin to that - it just might not have been formalized.) With what number do you label the first of something? Go on, say it! Which month of the year is this? On what date did it begin? Which century did Jesus Christ die in? With which year of the era did the era begin? >In astronomical dating, there is no BC: everything is AD, the year 1 AD is >preceded by the year 0 AD, which is preceded by -1 AD, preceded by -2, etc... > >Here's a way to remember it: Julius Caesar was assassinated on 15 March 44 BC, >historical dating, and -43 March 15, astronomical dating. Introducing a year 0 in order to make centuries of the era start when three digits change in the year number sets the cat squarely among the pigeons: If the BC era is to be retained and its centuries are also to change on such occasions, a year 0 BC would also have to be introduced! Then we'd have the years passing thus: ... BC 1, BC 0, AD 0, AD 1, .... A fine improvement! Unless the year AD 0 is called the "1st year" (rather than the "0th"), which I would have thought rather defeats the purpose, calling the years 0 to 99 the "1st century" would be inconsistent anyway: they should be referred to as century 0 (the 0th century?), and the years 0 to 9 as decade 0, and the years 1000 to 1999 as millennium 1 (the 1st millennium?) and the years 1900 to 1999 as century 19 (the 19th century?). If astronomical dating were to become the norm, what sense does a term like "1st century" make? What years did it consist of? Years 0 to 99 or years 1 to 100 (or years -14999999999 to -14999999899)? What was the century before it? The "0th"? What years did it consist of? Years -100 to -1 or years -99 to 0? Facts must be faced (though some would disagree with me there I'm sure): years, months and days are numbered like lines of poem, verses of a song, pages of a book, lots in a subdivision, diskettes in a box, and countless (pardon the pun) other things. That this means that the first 10 of anything includes the 10th, the first 100 the 100th, the first 1000 the 1000th, and the second 1000 and the twentieth 100 the 2000th simply cannot be got around. By all means celebrate the beginning of the 2000th year at the beginning of 2000; but let that be the beginning of a year-long party climaxing at the end when the 2000th year, the 200th decade, the 20th century and the 2nd millennium end and the 3rd millennium, the 21st century, the 201st decade and the 2001st year begin. (On the other hand these are just arbitrary numbers given very tenuous significance only because of the human race's extremely unfortunate choice of base 10 to count in - and Jesus Christ was almost certainly born in BC 7 or 6 anyway, so we're celebrating 2000 years since nothing in particular!) _______________ Alex LIVINGSTON Macintosh Support Computing & IT (C&IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) Sydney NSW 2052 AUSTRALIA E-mail : alex(a)agsm.unsw.edu.au; cit(a)agsm.unsw.edu.au (C&IT) Facsimile: +61 2 9313-7279 Telephone: +61 2 9931-9264

2 1

Re: -00:00 on draft-newman-datetime-00.txt
by alex＠agsm.unsw.edu.au Jan. 6, 1997

Jan. 6, 1997

Robert Elz writes: > Date: Thu, 02 Jan 1997 21:46:47 -0500 > From: kuhn(a)cs.purdue.edu ("Markus G. Kuhn") > Message-ID: <199701030246.VAA09620(a)ector.cs.purdue.edu> [snip] > We go even one step further and remove the redundant minute offset digits. > >The minutes offset is certainly not redundant. I find it hard to >believe that anyone who knows anything about time zones can believe >that. In Australia right now there are two different time zones >that are not even hours. +1030 and +0930. There are two only >because the former (further south) has summer time (it isn't >daylight saving time in Aust, it is Summer Time) and the northern >section (which gets close to the equator, and well into the tropics) >doesn't. Acutally, there are no fewer than *four* off-the-hour time "zones" in effect in Australian territory at the moment. Besides the two mentioned above, there is Cocos Islands time (+06:30) and Norfolk Island time (+11:30). When daylight saving is not in effect, there are still four, as, absurdly, Lord Howe Island (east of NSW) changes from +11:00 to +10:30. >There are also half hour offsets in India, and other places. Besides those already mentioned there is Burma (+06:30), Afganistan (+04:30), Iran (+03:30), Sri Lanka (+06:30, an hour ahead of India, but only since very recently), island of Newfoundland (-03:30/-01:30, if it's true that double summer time is used there), Marquesas Islands (-09:30), Pitcairn and some other islands in the south Pacific (-08:30). There are also two quarter-hour (or should one say "three-quarter-hour") time-zone offsets in effect: Nepal (+05:45) and Chatham Islands (+12:45/+13:45), east of New Zealand. However, over the last half century or so there has, thankfully, been a general reduction in the number of off-hour time zones in use in the world. [snip] >That might not need a lookup table, but it is ambiguous, and >much much worse. You certainly wouldn't have got 19970103 >as that's horrid for humans to parse, and unknown in the US >(and generally here as well, if that matters). 19970103 is only difficult for humans to parse because of the lack of separators. I cannot believe that implementing this obviously superior and consistent ordering of numeric date specifications is harder to understand than the two other orderings in common use. Several countries already use it, e.g. Sweden, Hungary and China (and, I believe, until it was corrupted by the US, Japan). If fact I think it could and should be made a worldwide standard. Just think how much confusion would be avoided, and in how much better an order things labeled with dates would sort into. [snip] _______________ Alex LIVINGSTON Macintosh Support Computing & IT (C&IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) Sydney NSW 2052 AUSTRALIA E-mail : alex(a)agsm.unsw.edu.au; cit(a)agsm.unsw.edu.au (C&IT) Facsimile: +61 2 9931-9349 Telephone: +61 2 9931-9264

1 0

The year 0 AD
by Chris Carrier Jan. 3, 1997

Jan. 3, 1997

"Markus G. Kuhn" > INTERNET:kuhn@cs.purdue.edu >ISO 8601 provides no way to represent years before the year 0000, or >after the year 9999. This makes it difficult to represent timestamps >in some historical applications. To fix this, you might extend the >syntax for date-fullyear to: date-fullyear = ["-"] 4*DIGIT >where the years are numbered ..., -0002, -0001, 0000, 0001, 0002, .... >(Note that unlike the traditional Julian calendar, there is a year 0 >in the modern Gregorian calendar.) WRONG! Negative year numbers are not part of the Gregorian calendar. There are two ways to number years before 1 AD, astronomical and historical. In historical dating, the year 1 AD is preceded by 1 BC, as there was no concept of 0 in Western civilization when Exigius set up the Anno Domini year count in AD 532. In astronomical dating, there is no BC: everything is AD, the year 1 AD is preceded by the year 0 AD, which is preceded by -1 AD, preceded by -2, etc... Here's a way to remember it: Julius Caesar was assassinated on 15 March 44 BC, historical dating, and -43 March 15, astronomical dating.

1 0

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

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

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

Internet Profile for ISO 8601
by kuhn＠cs.purdue.edu Dec. 28, 1996

Dec. 28, 1996

You might be interested in reviewing the new Internet draft standard ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt which describes the future recommended Internet date and time notation for new applications. This standard describes a subset of ISO 8601 and recommended usage practice. For more information about ISO 8601, see also http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html The draft-newman-datetime-00.txt is still an early draft and could require some input from the date and time experts here. In addition, I also wanted to mention that all ITU-R TF Recommendations can now be ordered on-line from http://www.itu.int/itudoc/itu-r/rec/tf.html This includes for instance ITU-R TF.460-4, the standard that defines UTC. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

tzcode1996o.tar.gz and tzdata1996n.tar.gz
by ado Dec. 28, 1996

Dec. 28, 1996

The files ftp://elsie.nci.nih.gov/pub/tzcode1996o.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1996n.tar.gz are now available; these incorporate Paul Eggert's latest changes. --ado

1 0