January 1997 - tz - lists.iana.org

Re: draft-newman-datetime-01.txt
by Chris Newman Jan. 31, 1997

Jan. 31, 1997

I have a proposal for dealing with the "T" problem: How about at the end of section 5.2, I mention that it may be desirable to substitute a " " for the "T" when displaying times to users (of course the "T" would still be required for Internet protocol interchange). Does this sound like a reasonable compromise?

2 3

I-D ACTION:draft-newman-datetime-01.txt (fwd)
by Chris Newman Jan. 30, 1997

Jan. 30, 1997

Here's a new version of the time format document. The major change is adding a new format to represent future dates by specifying timezone name. Something like this seems to be needed by the IETF calendaring/scheduling working group to deal with future events and recurring events scheduled in local timezones. ---------- Forwarded message ---------- Date: Tue, 28 Jan 1997 09:40:43 -0500 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-newman-datetime-01.txt A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Date and Time on the Internet Author(s) : C. Newman Filename : draft-newman-datetime-01.txt Pages : 23 Date : 01/27/1997 Date and time formats cause a lot of confusion and interoperability problems on the Internet. This document will address many of the problems encountered and make recommendations to improve consistancy and interoperability when representing and using date and time in Internet protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-newman-datetime-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-datetime-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-datetime-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

3 5

Alternative to A/B notation
by Chris Carrier Jan. 29, 1997

Jan. 29, 1997

Paul Eggert > INTERNET:eggert@twinsun.com wrote: >I agree with most of Markus Kuhn's comments and have the following >further comments and suggestions. >* I agree with Markus that ambiguous local times are a problem, but >the proposed A/B notation is not an adequate solution. That notation >works in the European context, where the rules are simple and uniform, >but it won't work well in general and it's painful to implement reliably. (major snip dealing with problems with A/B notation) >Here's a counterproposal that avoids the above problems. Instead of >having a special A/B notation for ambiguous local times, simply >have section 6.7 require the UTC offset. That is, instead of > 1996-10-27T02:30:00A Europe/Paris [+02:00] > 1996-10-27T02:30:00B Europe/Paris [+01:00] >(where the bracketed items are optional), require the UTC offset instead: > 1996-10-27T02:30:00 Europe/Paris +02:00 > 1996-10-27T02:30:00 Europe/Paris +01:00 >This counterproposal simplifies the notation and removes options, >which is a stated goal of the draft. I completely agree with Paul Eggert's suggestion. >* In practice the choice of time zone rule names may be controversial. >To encourage standardization and head off as much controversy as possible, >I'd like to echo Markus's suggestion to add (to the draft's section 6.3) >as much as possible from the advice to submitters of new time zone >rule names, taken from the `africa' file of the ><URL:ftp://elsie.nci.nih.gov/pub/> registry. My advice here would be to avoid using time zone names/acronyms, period. After all EST means either -05:00, +10:00 or +11:00 depending on nationality and time of year. If, however, time zone acronyms and names have to be used, I would urge 'daylight time' instead of 'summer time' as both standard and summer begin with the same letter, creating further confusion; in Australia, EST can be either +10:00 or +11:00 as mentioned above. Chris Carrier

1 0

Indiana time zoning
by Chris Carrier Jan. 29, 1997

Jan. 29, 1997

samrein(a)mainlink.net wrote on the Subj: Indiana Daylight Savings Time >I was just told today that Indiana only has 4 counties that change time >twice a year. Can you tell me which 4 and why? My latest information has 11 counties in Indiana; 6 in the NW part of the state and 5 in the SW; on CST in winter and CDT in summer. The rest of the state keeps EST all year. The reason for the counties in the NW being on CT all year is because they are part of suburban/exurban Chicago and prefer being on Chicago time. The counties in the SW have similar economic ties to Central Time areas in neighboring states and prefer being on Central Time for that reason. The history of Indiana time zoning is more than a little interesting, and I have a fascinating and ahem, rather personal story about it that I will send anyone who is interested. In 1883, when standard time was promulgated by the railroads, Indiana went on CST without much complaint. Indiana observed CDT during the summer-time periods of 1918-19 and all year under the name Central War Time during the American World War II year-round summer-time period of 1942-02-09 to 1945-09-30. It was here that things began to get interesting. At the end of War Time, half of Indiana decided it liked being on CDT or EST all year and the other half didn't. Therefore, from 1946 onwards, you have the phenomenon of counties deciding what time they wished to be on, cities within those counties deciding they didn't like the county decision and adopting their own time, and even some neighborhoods split with one side of town adopting DST and the other not, or a town being on one time and its post office on another, ad nauseum. Shanks has tracked down 255 separate rules for Indiana time zoning on the postwar period, and I'm quite sure even he missed a lot of the little rules. Aggravating this after 1954 is indeterminacy as to whether the summer-time period should end on the last Sunday in September or October (September was near universal 1921-41 and 1946-54, and should still be, IMHO). In the early 1960s there was more confusion as the summer-time period began in most jurisdictions on the last Sunday in April, but in a few was delayed until late May, usually a Sunday preceding or following or the day of US Memorial Day (at that time, May 30 in all years; and in many of these jurisdictions DST ended on either the day of, the day before or the day after US Labor Day; the 1st Monday in September). It remember reading in a magazine printed in the mid-1960s that there was a 35 mile stretch of road in Indiana where the clocks changed 7 times. The Eastern/Central boundary crept west during this period, and was officially moved to cover half of Indiana in 1961, and most of it, excepting the counties that are still on Central, on the last Sunday in April 1970. The Uniform Time Act of 1967 required Indiana to clean its time act up. The Indiana Legislature's response to this was to pass a law requiring one clock in each county courthouse to be set to and be labeled 'official time' and allowed localities to go on as before. The 1972 amendment to the Uniform Time Act allowed states such as Indiana in split time zones to except the zone on the later time from DST. As soon as it was passed the Eastern Zone area of Indiana so exempted itself. As such it remained on EST during the expanded summer time periods of 1974-5. Even today, there is still some un-official time in Indiana, in the counties near the Ohio border, which are officially on EST all year, but some informally use EDT in the summer time period while using EST as the time recorded on official documents such as birth records, timestamping of deeds, etc... Personally they should have stayed in the Central Zone where they astronomically belong. Ohio should have been the scene for this mess (but Ohio has some interesting time tales of its own). Chris Carrier

1 0

Re: Inverse for gmtime() ??
by ncm＠cantrip.org Jan. 21, 1997

Jan. 21, 1997

Chris Newman <Chris.Newman(a)innosoft.com>: > On Mon, 20 Jan 1997, Markus G. Kuhn wrote: > > 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. > > You can do a binary search of the time_t space using the gmtime() > function. This does require the assumption that time_t is an integral > type, but works well. There is no reason to assume that time_t is integral, and good reasons to assume it often is not, and more often in the future than at present. The restricted range of 32-bit time_t values is a problem in common applications, and until 64-bit machines are universal the easiest way to sidestep the problem is "typedef double time_t;". In any case, since time is a continuous quantity a floating-point representation makes perfect sense, and ANSI (aware of this) permits it. Nathan Myers ncm(a)cantrip.org

2 1

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. 20, 1997

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

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

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

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

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

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