- tz - lists.iana.org

Inverse for gmtime() ??
by kuhn＠cs.purdue.edu Jan. 21, 1997

Jan. 21, 1997

I just wanted to start writing a ISO 8601 subset -> time_t conversion routine, but to my great disappointment I discovered that ISO C does not seem to allow portable conversion of a broken-down time into time_t. In other words, while mktime() is the inverse function to localtime(), there exists no mkgmtime() that is the inverse function to gmtime(). I knew that the C standard library time API is a strange design, but I had no idea that it was *that* bad. The only practical way to get from a broken-down UTC time to time_t seems to be to assume that we are on a POSIX system where the time_t representation is exactly specified. Or did I miss something? In case someone of you is in contact with the folks revising ISO C, I have now a whole list of things that should be fixed in time.h: - add inverse function for gmtime() (mkutime() or mkgmtime()) - add to strftime() conversion specifiers for ISO 8601 week-of-year and year-of-week. - remove the second leap second 61 mentioned in the footnote (contradicts to UTC definition) Instead of adding an inverse function for gmtime, one could also extend struct tm by a new field tm_offset, which is in seconds the difference between the time in the struct tm and the corresponding universal time (in my opinion a much cleaner solution than the tm_isdst hack). But I guess, this might break existing code that does not initialize tm_offset ... Having a tm_offset in struct tm would however still be a good idea as this would allow to implement in strftime() conversion specifiers for the time zone offset (much more interesting than the time zone name). Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

3 2

tzcode1997a.tar.gz and tzdata1997a.tar.gz
by ado Jan. 21, 1997

Jan. 21, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997a.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997a.tar.gz are now available. These include Paul Eggert's Antarctica (and other changes). I've finessed the "getopt" issue by checking against both -1 and EOF (regardless of POSIX, SunOS 4.1.1's manual says -1 is returned while SunOS 5.5's manual says EOF is returned). --ado

1 0

interested in your mailing list
by Wayne Olsen Jan. 21, 1997

Jan. 21, 1997

send me information please wayne olsen

1 0

More about Antartica
by Antoine Leca Jan. 21, 1997

Jan. 21, 1997

Hello, I've dig up some informations about timezones in the French Southern Territories. First, a Web page in English is available at <URL:http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html>. IFRTP (Institut Français pour la Recherche et la Technologie Polaire) is the French organism in charge of the scientific stations there. They don't have a web page of their own presently. When they will have one, it will be linked in the proper place in <http://www.mesr.fr/organism.htm>. I called this organism, and Mrs. Nicole Pailleau which is in charge of the communications with the remote stations gave me the local hours there. She confirms me that no stations use daylight saving time, even Terre Adelie that is connected with Tasmania for support. There is really two different zones: * one is the islands in the Southern Indian Ocean, namely Kerguelen, Crozet, Amsterdam and Saint-Paul. There are 3 meteorologic bases, in the Kerguelen, in Crozet and in Amsterdam. They are constantly at UTC+5: Martin-de-Viviès Base, Amsterdam Island, -374105+0773155, since 1950 30 persons in winter, 50 in summer Port-aux-Français, Kerguelen Islands, -492110+0701303, since 1951 80 persons in winter, 120 in summer Alfred-Faure Base, Crozet Islands, -462551+0515152, since 1964 35 persons in winter, 50 in summer St Paul Island, near Amsterdam, is uninhabited since 1927 The islands were inhabited by whale-hunters (with oil factories) in the 1920's. They are supported from the island of Réunion. Since they are really in the Indian Ocean, I give them the zone name of Indian/Kerguelen, the name of the largest island; Indian/Port_aux_Francais ought to be more appropriate, but too long. * the second is a base in the main continent, in a area called Terre Adélie. It is named Dumont-d'Urville, and it lies at UTC+10 all year round. It holds 35 persons in winter and 100 in summer. Previously, there were another base, named Port-Martin; it was destroyed by fire in 1954. I included it in the statitics about the past. Also, I read in <http://www.antdiv.gov.au/aad/exop/sfo/macca/macca_aws.html> that Macquarie Is is in the same timezone as Tasmania. But I don't know if it is inhabited all-year round. I joined two diff files about the changes. *** antarc~1 Sun Nov 24 02:07:38 1996 --- ant.new Mon Jan 20 19:47:06 1997 *************** *** 58,71 **** # France # # French Southern Territories with year-round inhabitants ! # Amsterdam Island ! # Crozet Islands ! # Kerguelen Islands ! # St Paul Island # ! # year-round base ! # Dumont d'Urville, Adelie Land, since IGY # Germany - year-round base # Georg von Neumayer --- 58,95 ---- # France # + # From Antoine Leca <Antoine.Leca(a)Renault.FR> (1996-01-20): + # Timezones from Nicole Pailleau at IFRTP (French institute). + # She confirms that French Southern Territories and Terre Adelie bases + # doesn't observe daylight saving time, even if Terre Adelie supplies came + # from Tasmania. + # # French Southern Territories with year-round inhabitants ! # ! # Martin-de-Vivies Base, Amsterdam Island, -374105+0773155, since 1950 ! # Alfred-Faure Base, Crozet Islands, -462551+0515152, since 1964 ! # Port-aux-Francais, Kerguelen Islands, -492110+0701303, since 1951 # ! # St Paul Island - near Amsterdam, uninhabited since 1927 ! # ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Indian/Kerguelen 0 - ___ 1950 # Port-aux-Francais ! 5:00 - TFT # ISO code TF Time ! # ! # year-round base in the main continent ! # Dumont-d'Urville, Terre Adelie (Adelie Land), -6040 +14001, since 1956-11 ! # ! # Previously, another base at Port-Martin, 50km east, was operated since 1947 ! # It was destroyed by fire on 1952-01-14 ! # ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Antarctica/DumontDUrville 0 - ___ 1947 ! 10:00 - PMT 1952 Jan 14 # Port-Martin Time ! 0 - ___ 1956 Nov ! 10:00 - DDUT # Dumont-d'Urville Time ! # References ! # <URL:http://www.icair.iac.org.nz/science/reports/fr/IFRTP.html> (1996-01-17). ! # Germany - year-round base # Georg von Neumayer *** zone.tab 1996-11-24 02:07:38 tzdata96n --- zone.tab 1997-01-17 18:38:22 tzdata *************** *** 34,39 **** --- 34,40 ---- AQ -6448-06406 Antarctica/Palmer Palmer Station, Anvers Island AQ -6736+06253 Antarctica/Mawson Mawson Station, Holme Bay AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula + AQ -6040+14001 Antarctica/DumontDUrville Dumont-d'Urville Base, Terre Adelie AR -3436-05827 America/Buenos_Aires E Argentina (BA, DF, SC, TF) AR -3257-06040 America/Rosario NE Argentina (SF, ER, CN, MN, CC, FM, LP, CH) AR -3124-06411 America/Cordoba W Argentina (CB, SA, TM, LR, SJ, SL, NQ, RN) *************** *** 310,315 **** --- 311,317 ---- SZ -2618+03106 Africa/Mbabane TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena + TF -492110+0701303 Indian/Kerguelen TG +0608+00113 Africa/Lome TH +1345+10031 Asia/Bangkok TJ +3835+06848 Asia/Dushanbe

2 1

Re: minor fixes for tzcode1996o
by ado＠elsie Jan. 20, 1997

Jan. 20, 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. > ... > --- time/localtime.c Mon Jan 13 20:17:09 1997 > ... > - if ((strlen(p) + strlen(name) + 2) >= sizeof fullname) > + if ((strlen(p) + strlen(name) + 1) >= sizeof fullname) > return -1; > ... There's a problem if the number of characters in a to-be-generated full file name (exclusive of the trailing '\0') equals or exceeds the size of the filename buffer. The number of characters (exclusive of the trailing '\0') is strlen(p) + strlen(name) + 1 (where the "1" is for the slash that separates the directory from the name) and the size of the filename buffer is sizeof fullname It looks to me as if the above test is correct; does anyone see something I've missed? > --- time/zdump.c Mon Jan 13 20:17:17 1997 > ... > (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); > - buf[(sizeof buf) - 1] = '\0'; > ... > (void) strncpy(buf, abbr(&newtm), > (sizeof buf) - 1); > - buf[(sizeof buf) - 1] = '\0'; > ... > (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); > - loab[(sizeof loab) - 1] = '\0'; The strncpy's above all have static arrays as their destinations; since the static array's are initialized to '\0's, and since the strncpy's can't change the last positions in the arrays (given the "- 1"s in the strncpy arguments), the sets of the last elements to '\0' seem unneeded. Does anyone see something I've missed? > --- time/zic.c Wed Jan 15 16:41:36 1997 > ... > - while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != -1) > + while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF) If anyone knows a good way of conditionalizing this (to cope with, for example, SunOS 4.1.1), I'd appreciate hearing from you. --ado

2 1

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