January 1997 - tz - lists.iana.org

[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