January 1997 - tz - lists.iana.org

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

Jan. 7, 1997

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

1 0

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

Jan. 6, 1997

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

1 0

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

Jan. 6, 1997

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

2 1

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

Jan. 6, 1997

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

1 0

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

Jan. 3, 1997

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

1 0

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

Jan. 3, 1997

Here are some comments on the time-zone-related parts of your Internet Draft ``MIME Calendaring and Scheduling Content Type'' <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-csct-00.txt> (November 1996). Please let me know if you have any questions about these comments, and I'd appreciate hearing about any updates to your draft. The comments below are similar to comments I've made about draft-ietf-calsch-sch-00.txt and draft-newman-datetime-00.txt, which I can forward if you're interested. 3.1.3.7 Date and Time The examples do not match the grammar in the use of the character `T' to separate date and time. The grammar specifies date followed by time; the examples use `T'. The grammar is to be preferred here. Common practice (allowed by ISO 8601) is to write the date followed by a space followed by time; this is easier for humans to read. ISO 8601 allows fractions to be preceded by `.' instead of `,'; this should be allowed by the grammar. The grammar allows a utc-offset without a sign; this should be fixed, as utc-offsets always have a sign in ISO 8601. Also, common practice (allowed by ISO 8601) is to omit the `:' and minutes of a UTC offset when minutes are zero. Here is a proposed patch: utc-offset = (_+_ / _-_) hour [[_:_] minute] Following the above suggestions, the examples can be expressed as follows in the extended notation: 1996-04-15 08:30:00-05 1996-04-15 13:30:00Z 3.1.5.2 Daylight Savings Rule 3.1.5.5 Time Zone The underlying model in these sections is too simplistic. It assumes that there is a ``standard time zone'' for the home calendar system, together with a single date and time for entering and exiting daylight saving time. However, locations sometimes alter the UTC offset of standard time (e.g. Portugal and Sri Lanka in 1996). Also, some locales have observed double daylight saving time for part of the summer (e.g. Britain in 1947), and two transitions do not suffice to represent this. The model should be fixed to allow an arbitrary sequence of UTC offset changes. If necessary, each change could be labeled by a daylight saving flag (to say whether the resulting time is considered to be ``daylight saving''), and a string label (e.g. `EST') that can be internationalized (e.g. to `HNE' for French-speakers in Montreal). I suggest that you consult the public domain time zone database maintained by Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated regularly) for ideas about how time zone and daylight saving information could be represented. For example, you could pass labels that identify time zone and daylight saving rules. In the Olson scheme, the label `America/Los_Angeles' identifies the complete UTC offset history for Los Angeles from to the introduction of standard time in 1883 to the indefinite future. The Olson database is updated as governments change the rules, so the label `America/Los_Angeles' can be used by application programs without worrying about the details. By the way, the proper term is ``daylight saving time'', not ``daylight savings time'' (at least, that is what the OED and the Random House Unabridged Dictionary prefer).

1 0

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

Jan. 3, 1997

Here are some comments on the time-zone-related parts of your Internet Draft ``MIME application/calendar Content Type'' <URL:ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-sch-00.txt> (November 1996). Please let me know if you have any questions about these comments, and I'd appreciate hearing about any updates to your draft. The comments below are similar to comments I've made about draft-ietf-calsch-csct-00.txt and draft-newman-datetime-00.txt, which I can forward if you're interested. 3.2.3.19 TZID This section suggests that it is ``likely that we want an IANA registry of time zone/daylight rule names''. I suggest that you consult the public domain time zone database maintained by Olson et al (<URL:ftp://elsie.nci.nih.gov/pub/>, updated regularly) for ideas about how such a registry should be maintained. The Olson scheme is an upward-compatible extension of the Posix TZ string representation for time zone and daylight saving rules. For example, in the Olson scheme, the label `America/Los_Angeles' identifies the complete UTC offset history for Los Angeles from to the introduction of standard time in 1883 to the indefinite future. The Olson database is updated as governments change the rules, so the label `America/Los_Angeles' can be used by application programs without worrying about the details. It should be easy to convert the Olson database to any proposed IANA registry of time zone and daylight saving info. Perhaps, as a first cut, you could start with the Olson database as the IANA registry. You might contact the mailing list tz(a)elsie.nci.nih.gov if you are interested in using their work. 3.2.3.20 TZBias 3.2.3.21 TZDstBias 3.2.3.22 TZStdBias 3.2.3.23 TZStdTrans 3.2.3.24 TZDstTrans 3.3.1.2 Definitions 3.3.1.4 Recurring Event Date and Time Specification The underlying model in these sections is too simplistic. It assumes that there is a ``standard time zone'' for the home calendar system, together with a single date and time for entering and exiting daylight saving time. However, locations sometimes alter the UTC offset of standard time (e.g. Portugal and Sri Lanka in 1996). Also, some locales have observed double daylight saving time for part of the summer (e.g. Britain in 1947), and TZStdBias does not suffice to represent this. The model should be fixed to allow an arbitrary sequence of UTC offset changes. If necessary, each change could be labeled by a daylight saving flag (to say whether the resulting time is considered to be ``daylight saving''), and a string label (e.g. `EST') that can be internationalized (e.g. to `HNE' for French-speakers in Montreal). This would be simpler and more accurate than the model in draft-ietf-calsch-sch-00.txt. I suggest that you consult the Olson database for ideas about how time zone and daylight saving information could be represented. 3.3.1.2 Definitions The proper term is ``daylight saving time'', not ``daylight savings time'' (at least, that is what the OED and the Random House Unabridged Dictionary prefer). ``Pacific Daylight Savings Time'' should be ``Pacific Daylight Time''. 3.3.1.4 Recurring Event Date and Time Specification This section does not address the problem of ``impossible times'' (e.g. `1996-04-07 02:30:00', which does not denote a valid local time in Los Angeles) or ``ambiguous times'' (e.g. `1996-10-27 01:30:00', which denotes two distinct valid local times in Los Angeles). When a time is converted from some locale to UTC, it may be found to be impossible or ambiguous; in that case, what should a scheduling application do?

1 0

time zone article
by Joe Celko [71062,1056] Jan. 1, 1997

Jan. 1, 1997

I am writing a book on data and databases. I need a short piece on timezones, UTC, leap seconds, etc. for the section on temporal data. If anyone has the time (pun) and would like to contribute, I can pay them a few bucks for their effort. I am more interested in getting the data than in getting a finished ready-to-publish article. Here is my biosketch by way of introduction: BIOSKETCH: Joe Celko is an Atlanta-based consultant with Northern Lights Software Ltd. and has been a member of the ANSI X3H2 Database Standards Committee since 1987 and helped write the ANSI/ISO SQL-89 and SQL-92 standards. Joe Celko has had several regular monthly or biweekly columns in the past eleven years in the computer trade and academic press. His current columns are: "SQL Explorer" in DBMS (Miller-Freeman), "WATCOM SQL Corner" in POWERBUILDER DEVELOPERS' JOURNAL (SysCon). Most recently, Mr. Celko also wrote: "Celko on SQL" in DATABASE PROGRAMMING & DESIGN (Miller-Freeman); "SQL Puzzle" in BOXES & ARROWS (Frank Sweet Publishing); "DBMS/Report" in SYSTEMS INTEGRATION (Cahner-Ziff); "Data Desk" in TECH SPECIALIST (R&D), "Data Points" in PC TECHNIQUES (Coriolis Group), "Celko on Software" in COMPUTING (VNC Publications, UK). and was editor for the "Puzzles & Problems" section of ABACUS (Springer-Verlag). Joe Celko is the author of four books on SQL: SQL FOR SMARTIES (Morgan-Kaufmann, 1995), INSTANT SQL (Wrox Press,1995), SQL PUZZLES & SOLUTIONS (Morgan-Kaufmann, 1997) and SECRETS OF THE SQL MASTER (Sys-Con, 1996). He is currently do a series under his name for Morgan-Kaufmann publishers. Joe Celko is a regular speaker and SQL instructor for Digital Consulting Inc., Norm DiNardi Enterprises, Boston University Corporate Education Center and Miller-Freeman Seminars. --CELKO--

1 0