December 1996 - tz - lists.iana.org

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

16 Jan '97

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

comments on draft-newman-datetime-00.txt
by Paul Eggert 09 Jan '97

09 Jan '97

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

Internet Profile for ISO 8601
by kuhn＠cs.purdue.edu 28 Dec '96

28 Dec '96

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

1 0

tzcode1996o.tar.gz and tzdata1996n.tar.gz
by ado 27 Dec '96

27 Dec '96

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

1 0

Re: Timezone naming
by Janis.Papanagnou＠pc-plus.DE 27 Dec '96

27 Dec '96

Markus wrote: > The time zone string CET or MET is never parsed by any software, because in > all applications (e-mail, news, etc.) the time format standards require > that a numeric local time - UTC offset is also provided (e.g., required by > RFC822 except for US names) and the numeric value is then used. Therefore, > MET->CET is no compatibility problem. That seems quite reasonable. A formal scheme is what I expect when handling time zones (myself or by application). > Consequently: Only humans have to recognize the time zone abbreviation > and it definitely does not make sense here to use one that does not > follow common practice (Langenscheid, PTB, SkyTV, CNN, etc.). That's the point, humans should be provided a user-friendly naming scheme. But I cannot second your conclusions. The US time zone "names" are very strange (to me!), but I don't care - it's not my domain, I have not to use them. CNN, etc. is not what I would call common practice; in DE I hear the terms MEZ (or MET). I am not talking with the PTB, nor do I inform myself by US broadcasts. Talking about i18n: are these TZ "names" really considered a matter of international standards ? Concerning computer variable TZ, I doubt it. Concerning the definition of an international standard, I do not think that the current 3-letter TZ "names" serve for i18n-"codes"; they are neither formal nor intuitive. As posted some weeks ago, ambiguities and coincidences happen to exist, too. The Olsen DB as a quasi-standard on computers shall fulfill demands of an IS ? To come back to the user-friendliness: the three letter "names" are easily misinterpreted (from a global view); I would prefer something intuitive. Janis

3 2

Australian time zoning
by Chris Carrier 23 Dec '96

23 Dec '96

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. 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. 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. >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. The least justifiable of these is "Central Time", and Lord Howe Island comes a close second, what with its almost entirely pointless daylight-saving practices. (I started a message about the latter several weeks ago but haven't got round to finishing it yet.): 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 >(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!). Actually if I lived in Kununurra I would want to keep UT+8:45 as opposed to either UT+8 (and certainly +9:30!). Given that LMT is probably about UT+8:35 (since the WA-NT border is +8:36), +8:45 is better than +8, +9, or +9:30. It would also be WA+0:45 and NT-0:45. >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. I like this idea better than idea 1.

1 0

No progress on EU eighth summertime directive
by peter＠aldie.co.uk 20 Dec '96

20 Dec '96

There still doesn't appear to be much action on getting the next (eighth) EC Directive on summertime arrangements finalised. My contact in the EC Information Office in Edinburgh produced the following response from Brussels in mid November: `Theoretically the proposal should be adopted by the end of the year. Nevertheless European Parliament having not adopted its opinion yet, we do not know if the Council will be able to adopt a common postion by this date. In this case the final adoption might be in early spring.' She also sent me some newspaper clippings from 29 Nov that said the European Parliament had `backed plans to have the European Union change to summertime on the same day to end the disruption caused when some states are out of phase with the rest'. As we are already in this state this can only be a reference to the French proposals to opt out of Summer Time altogether. I didn't think that the European Parliament had much role in adopting directives. I was going to point to the Commission's UK web pages at http://www.cec.org.uk for a page which explained the directive creation process but it seems to have vanished since I last looked. I am pretty sure that this directive is controlled by the EU transport ministers. They had a meeting on 12--13 December. They did not discuss the issue, or at least if they did it wasn't mentioned in the press release after the meeting, and they certainly didn't decide anything. The next (informal) meeting is on 31 Jan 97. The next formal meeting is on 11 Mar 97. Lots of diary publishers are probably getting worried. I hope that the EU isn't organising any sort of Millennium event. I would hope that even they would be embarrassed by missing that deadline. :-) Peter Ilieve peter(a)aldie.co.uk

1 0

Re: Probable change needed to the Aust zone files
by alex＠agsm.unsw.edu.au 19 Dec '96

19 Dec '96

>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. 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). The least justifiable of these is "Central Time", and Lord Howe Island comes a close second, what with its almost entirely pointless daylight-saving practices. (I started a message about the latter several weeks ago but haven't got round to finishing it yet.) 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 (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. In either case, a section of northeast WA could consider adopting UT+9 year-round. What chance of this? _______________ 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

1 0

Probable change needed to the Aust zone files
by Robert Elz 18 Dec '96

18 Dec '96

This is pretty minor, and may not be worth bothering with, but we do try to cover everything, so ... 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). I hope to check this if I can find someone to check it with, and see if I can discover when it happened exactly. I wouldn't be in any great hurry to get this fixed, this is going to be one small town, and I would doubt very much that anyone there is running the tz code in any form... kre

1 0

proposed tz patches for post-1991 Iran, 1930s Soviet week, spelling
by Paul Eggert 17 Dec '96

17 Dec '96

Rich Wales suggested that Iran's daylight-saving rules correspond to the Persian calendar and I found another expert source who agrees. This clarifies the daylight saving rules for Iran (and points out what appear to be minor errors in the IATA SSIM). Here's a patch embodying his suggestion, along with a better explanation of the Soviet week from 1929 through 1940 thanks to Chris Carrier, and some miscellaneous spelling fixes (including one fix to a message in `zic'). =================================================================== RCS file: RCS/zic.c,v retrieving revision 1996.14 retrieving revision 1996.14.1.1 diff -c -r1996.14 -r1996.14.1.1 *** zic.c 1996/12/16 14:42:02 1996.14 --- zic.c 1996/12/18 06:42:29 1996.14.1.1 *************** *** 1697,1703 **** (void) strcpy(startbuf, zp->z_format); eat(zp->z_filename, zp->z_linenum); if (*startbuf == '\0') ! error(_("can't determine time zone abbrevation to use just after until time")); else addtt(starttime, addtype(startoff, startbuf, startoff != zp->z_gmtoff, --- 1697,1703 ---- (void) strcpy(startbuf, zp->z_format); eat(zp->z_filename, zp->z_linenum); if (*startbuf == '\0') ! error(_("can't determine time zone abbreviation to use just after until time")); else addtt(starttime, addtype(startoff, startbuf, startoff != zp->z_gmtoff, =================================================================== RCS file: RCS/asia,v retrieving revision 1996.13 retrieving revision 1996.13.1.1 diff -c -r1996.13 -r1996.13.1.1 *** asia 1996/11/24 01:07:37 1996.13 --- asia 1996/12/18 06:42:29 1996.13.1.1 *************** *** 354,359 **** --- 354,379 ---- 9:00 - JAYT # Iran + # From Paul Eggert (1996-12-17), following up a suggestion by Rich Wales: + # Ahmad Alavi <URL:http://tehran.stanford.edu/Iran_Lib/Calendar/taghveem.txt> + # (1993-08-04) writes ``Daylight saving time in Iran starts from the first day + # of Farvardin and ends the first day of Mehr.'' This disagrees with the SSIM: + # + # DST start DST end + # year SSIM Alavi SSIM Alavi + # 1991 05-03!= 03-21 09-20!= 09-23 + # 1992 03-22!= 03-21 09-23 09-23 + # 1993 03-21 03-21 09-23 09-23 + # 1994 03-21 03-21 09-22!= 09-23 + # 1995 03-21 03-21 09-22!= 09-23 + # 1996 03-21!= 03-20 09-21!= 09-22 + # 1997 03-21 03-21 09-21!= 09-23 + # + # Go with Alavi starting with 1992. + # I used Ed Reingold's cal-persia in GNU Emacs 19.34 to compute Persian dates. + # The Persian calendar is based on the sun, and dates after around 2050 + # are approximate; stop after 2037 when 32-bit time_t's overflow. + # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Iran 1978 1980 - Mar 21 0:00 1:00 S Rule Iran 1978 only - Oct 21 0:00 0 - *************** *** 361,371 **** Rule Iran 1980 only - Sep 23 0:00 0 - Rule Iran 1991 only - May 3 0:00s 1:00 S Rule Iran 1991 only - Sep 20 0:00s 0 - ! Rule Iran 1992 only - Mar 22 0:00 1:00 S ! Rule Iran 1992 1993 - Sep 23 0:00 0 - ! Rule Iran 1993 max - Mar 21 0:00 1:00 S ! Rule Iran 1994 1995 - Sep 22 0:00 0 - ! Rule Iran 1996 max - Sep 21 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tehran 3:25:44 - LMT 1916 3:25:44 - TMT 1946 # Tehran Mean Time --- 381,430 ---- Rule Iran 1980 only - Sep 23 0:00 0 - Rule Iran 1991 only - May 3 0:00s 1:00 S Rule Iran 1991 only - Sep 20 0:00s 0 - ! Rule Iran 1992 1995 - Mar 21 0:00 1:00 S ! Rule Iran 1992 1995 - Sep 23 0:00 0 - ! Rule Iran 1996 only - Mar 20 0:00 1:00 S ! Rule Iran 1996 only - Sep 22 0:00 0 - ! Rule Iran 1997 1999 - Mar 21 0:00 1:00 S ! Rule Iran 1997 1999 - Sep 23 0:00 0 - ! Rule Iran 2000 only - Mar 20 0:00 1:00 S ! Rule Iran 2000 only - Sep 22 0:00 0 - ! Rule Iran 2001 2003 - Mar 21 0:00 1:00 S ! Rule Iran 2001 2003 - Sep 23 0:00 0 - ! Rule Iran 2004 only - Mar 20 0:00 1:00 S ! Rule Iran 2004 only - Sep 22 0:00 0 - ! Rule Iran 2005 2007 - Mar 21 0:00 1:00 S ! Rule Iran 2005 2007 - Sep 23 0:00 0 - ! Rule Iran 2008 only - Mar 20 0:00 1:00 S ! Rule Iran 2008 only - Sep 22 0:00 0 - ! Rule Iran 2009 2011 - Mar 21 0:00 1:00 S ! Rule Iran 2009 2011 - Sep 23 0:00 0 - ! Rule Iran 2012 only - Mar 20 0:00 1:00 S ! Rule Iran 2012 only - Sep 22 0:00 0 - ! Rule Iran 2013 2015 - Mar 21 0:00 1:00 S ! Rule Iran 2013 2015 - Sep 23 0:00 0 - ! Rule Iran 2016 only - Mar 20 0:00 1:00 S ! Rule Iran 2016 only - Sep 22 0:00 0 - ! Rule Iran 2017 2019 - Mar 21 0:00 1:00 S ! Rule Iran 2017 2019 - Sep 23 0:00 0 - ! Rule Iran 2020 only - Mar 20 0:00 1:00 S ! Rule Iran 2020 only - Sep 22 0:00 0 - ! Rule Iran 2021 2023 - Mar 21 0:00 1:00 S ! Rule Iran 2021 2023 - Sep 23 0:00 0 - ! Rule Iran 2024 2025 - Mar 20 0:00 1:00 S ! Rule Iran 2024 2025 - Sep 22 0:00 0 - ! Rule Iran 2026 2027 - Mar 21 0:00 1:00 S ! Rule Iran 2026 2027 - Sep 23 0:00 0 - ! Rule Iran 2028 2029 - Mar 20 0:00 1:00 S ! Rule Iran 2028 2029 - Sep 22 0:00 0 - ! Rule Iran 2030 2031 - Mar 21 0:00 1:00 S ! Rule Iran 2030 2031 - Sep 23 0:00 0 - ! Rule Iran 2032 2033 - Mar 20 0:00 1:00 S ! Rule Iran 2032 2033 - Sep 22 0:00 0 - ! Rule Iran 2034 2035 - Mar 21 0:00 1:00 S ! Rule Iran 2034 2035 - Sep 23 0:00 0 - ! Rule Iran 2036 2037 - Mar 20 0:00 1:00 S ! Rule Iran 2036 2037 - Sep 22 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tehran 3:25:44 - LMT 1916 3:25:44 - TMT 1946 # Tehran Mean Time *************** *** 492,498 **** # # ftp://ftp.huji.ac.il/pub/misc/timezones/announcements/1996-1998.ps.gz # ! # Emptor Caveat: The dates for the years 1996-1998 were originally announced # on 1995-08-31, by the previous Minister of Interior. The new Minister # of Interior changed the dates on 1996-01-01, to take into account the # desires of certain portions of Israeli society (the next election is in the --- 551,557 ---- # # ftp://ftp.huji.ac.il/pub/misc/timezones/announcements/1996-1998.ps.gz # ! # Caveat emptor: The dates for the years 1996-1998 were originally announced # on 1995-08-31, by the previous Minister of Interior. The new Minister # of Interior changed the dates on 1996-01-01, to take into account the # desires of certain portions of Israeli society (the next election is in the =================================================================== RCS file: RCS/australasia,v retrieving revision 1996.13 retrieving revision 1996.13.1.2 diff -c -r1996.13 -r1996.13.1.2 *** australasia 1996/11/24 01:07:37 1996.13 --- australasia 1996/12/18 06:59:16 1996.13.1.2 *************** *** 48,62 **** # so use Lindeman. # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule QL 1989 1991 - Oct lastSun 2:00s 1:00 - ! Rule QL 1990 1992 - Mar Sun>=1 2:00s 0 - Rule Holiday 1989 1993 - Oct lastSun 2:00s 1:00 - Rule Holiday 1990 1994 - Mar Sun>=1 2:00s 0 - Zone Australia/Brisbane 10:12:08 - LMT 1895 10:00 - EST 1917 Jan 1 0:01 10:00 Aus EST 1971 Oct lastSun 2:00s 10:00 1:00 EST 1972 Feb lastSun 2:00s ! 10:00 QL EST Zone Australia/Lindeman 9:55:56 - LMT 1895 10:00 - EST 1917 Jan 1 0:01 10:00 Aus EST 1971 Oct lastSun 2:00s --- 48,62 ---- # so use Lindeman. # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule AQ 1989 1991 - Oct lastSun 2:00s 1:00 - ! Rule AQ 1990 1992 - Mar Sun>=1 2:00s 0 - Rule Holiday 1989 1993 - Oct lastSun 2:00s 1:00 - Rule Holiday 1990 1994 - Mar Sun>=1 2:00s 0 - Zone Australia/Brisbane 10:12:08 - LMT 1895 10:00 - EST 1917 Jan 1 0:01 10:00 Aus EST 1971 Oct lastSun 2:00s 10:00 1:00 EST 1972 Feb lastSun 2:00s ! 10:00 AQ EST Zone Australia/Lindeman 9:55:56 - LMT 1895 10:00 - EST 1917 Jan 1 0:01 10:00 Aus EST 1971 Oct lastSun 2:00s *************** *** 339,345 **** 9:00 - PWT # Palau Time # Palmyra ! # uninhabited since World War II; was probably like Pacific/Kiritmati # Papua New Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] --- 339,345 ---- 9:00 - PWT # Palau Time # Palmyra ! # uninhabited since World War II; was probably like Pacific/Kiritimati # Papua New Guinea # Zone NAME GMTOFF RULES FORMAT [UNTIL] =================================================================== RCS file: RCS/europe,v retrieving revision 1996.13 retrieving revision 1996.13.1.1 diff -c -r1996.13 -r1996.13.1.1 *** europe 1996/11/24 01:07:37 1996.13 --- europe 1996/12/18 06:42:29 1996.13.1.1 *************** *** 78,84 **** # of the text said: # # `An old stone obelisk marking a forgotten terrestrial meridian stands ! # beside the river at Kew. In the 18th century, before time and longditude # was standardised by the Royal Observatory in Greenwich, scholars observed # this stone and the movement of stars from Kew Observatory nearby. They # made their calculations and set the time for the Horse Guards and Parliament, --- 78,84 ---- # of the text said: # # `An old stone obelisk marking a forgotten terrestrial meridian stands ! # beside the river at Kew. In the 18th century, before time and longitude # was standardised by the Royal Observatory in Greenwich, scholars observed # this stone and the movement of stars from Kew Observatory nearby. They # made their calculations and set the time for the Horse Guards and Parliament, *************** *** 86,92 **** # along the towpath within a few yards of it.' # # I have a one inch to one mile map of London and my estimate of the stone's ! # position is 51 deg. 28' 30" N, 0 deg. 18' 45" W. The longditude should # be within about +-2". The Ordnance Survey grid reference is TQ172761. # # [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.] --- 86,92 ---- # along the towpath within a few yards of it.' # # I have a one inch to one mile map of London and my estimate of the stone's ! # position is 51 deg. 28' 30" N, 0 deg. 18' 45" W. The longitude should # be within about +-2". The Ordnance Survey grid reference is TQ172761. # # [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.] *************** *** 167,173 **** # It ends at 02:00 GMT on the morning of the day after the fourth Saturday # in October. (All the redundant `morning of the day ...' is in the Act.) # This is only of passing interest now as it will always be overridden by ! # an Order in Council (a Statutary Instrument, the SI thing mentioned above) # to specify the EC specified dates. # From Peter Ilieve <peter(a)memex.co.uk> (1993-10-18): --- 167,173 ---- # It ends at 02:00 GMT on the morning of the day after the fourth Saturday # in October. (All the redundant `morning of the day ...' is in the Act.) # This is only of passing interest now as it will always be overridden by ! # an Order in Council (a Statutory Instrument, the SI thing mentioned above) # to specify the EC specified dates. # From Peter Ilieve <peter(a)memex.co.uk> (1993-10-18): *************** *** 327,333 **** # so that part of the 1922 Act will still apply. # # - The Defence (Summer Time) Regulations, 1939, SR&O 1939 No. 1379 ! # [SR&O == Statutary Regulation and Order] # # These were made under the Emergency Powers (Defence) Act, 1939. # It changes the end date to be the day after the third Saturday in November. --- 327,333 ---- # so that part of the 1922 Act will still apply. # # - The Defence (Summer Time) Regulations, 1939, SR&O 1939 No. 1379 ! # [SR&O == Statutory Regulation and Order] # # These were made under the Emergency Powers (Defence) Act, 1939. # It changes the end date to be the day after the third Saturday in November. *************** *** 403,409 **** # harmonise with the EC since 1981. The major change is that the time changes # to 01:00 GMT.) # ! # - The Summer Time Order, 1992, SI 1992/1729 [SI == Statutary Instrument] # # This specifies dates of: # Start End --- 403,409 ---- # harmonise with the EC since 1981. The major change is that the time changes # to 01:00 GMT.) # ! # - The Summer Time Order, 1992, SI 1992/1729 [SI == Statutory Instrument] # # This specifies dates of: # Start End *************** *** 1298,1304 **** 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks says they switched to C-Eur in 1981; ! # go with EU intead, since Greece joined it on Jan 1. 2:00 EU EE%sT # Hungary --- 1298,1304 ---- 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks says they switched to C-Eur in 1981; ! # go with EU instead, since Greece joined it on Jan 1. 2:00 EU EE%sT # Hungary *************** *** 1819,1827 **** 2:00 E-Eur EE%sT # Russia ! # From Shanks (1991): ! # In 1929 the Soviet Union instituted a 5 day week; in 1932 it instituted ! # a 6 day week; on 1940-06-27 it returned to the Gregorian week. # # From Paul Eggert <eggert(a)twinsun.com> (1996-11-22): # Except for Moscow after 1919-07-01, I invented the time zone abbreviations, --- 1819,1833 ---- 2:00 E-Eur EE%sT # Russia ! ! # From Chris Carrier <72157.3334(a)CompuServe.COM> (1996-12-02): ! # On 1929-10-01 the Soviet Union instituted an ``Eternal Calendar'' ! # with 30-day months plus 5 holidays, with a 5-day week. ! # On 1931-12-01 it changed to a 6-day week; in 1934 it reverted to the ! # Gregorian calendar while retaining the 6-day week; on 1940-06-27 it ! # reverted to the 7-day week. With the 6-day week the usual days ! # off were the 6th, 12th, 18th, 24th and 30th of the month. ! # (Source: Evitiar Zerubavel, _The Seven Day Circle_) # # From Paul Eggert <eggert(a)twinsun.com> (1996-11-22): # Except for Moscow after 1919-07-01, I invented the time zone abbreviations, *************** *** 1882,1888 **** # as far as I remember it was done exactly during winter->summer switching # so we (Novosibirsk) simply did not switch. Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 ! 6:00 - NOVT 1957 Mar # Novosibirsk TIme 7:00 Russia NOV%sT 1991 Mar 31 2:00s 6:00 1:00 NOVST 1991 Sep 29 2:00s 6:00 - NOVT 1992 Jan 19 2:00s --- 1888,1894 ---- # as far as I remember it was done exactly during winter->summer switching # so we (Novosibirsk) simply did not switch. Zone Asia/Novosibirsk 5:31:40 - LMT 1924 May 2 ! 6:00 - NOVT 1957 Mar # Novosibirsk Time 7:00 Russia NOV%sT 1991 Mar 31 2:00s 6:00 1:00 NOVST 1991 Sep 29 2:00s 6:00 - NOVT 1992 Jan 19 2:00s *************** *** 2134,2140 **** # Ukraine # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ukraine 1917 only - Jul 1 23:00 1:00 UST # Ukrainian Summer Time ! Rule Ukraine 1917 only - Dec 28 0:00 0 KMT # Kiev Mean TIme Rule Ukraine 1918 only - May 31 22:00 2:00 UDST # Ukrainian Double Summer Time Rule Ukraine 1918 only - Sep 17 0:00 1:00 UST Rule Ukraine 1919 only - May 31 23:00 2:00 UDST --- 2140,2146 ---- # Ukraine # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ukraine 1917 only - Jul 1 23:00 1:00 UST # Ukrainian Summer Time ! Rule Ukraine 1917 only - Dec 28 0:00 0 KMT # Kiev Mean Time Rule Ukraine 1918 only - May 31 22:00 2:00 UDST # Ukrainian Double Summer Time Rule Ukraine 1918 only - Sep 17 0:00 1:00 UST Rule Ukraine 1919 only - May 31 23:00 2:00 UDST =================================================================== RCS file: RCS/northamerica,v retrieving revision 1996.13 retrieving revision 1996.13.1.1 diff -c -r1996.13 -r1996.13.1.1 *** northamerica 1996/11/24 01:07:37 1996.13 --- northamerica 1996/12/18 06:42:29 1996.13.1.1 *************** *** 920,928 **** # MEXICO BAJA CAL N 7 H BEHIND UTC BAJA CALIFORNIA SUR AND # MEXICO BAJA CAL N N. PACIFIC COAST (STATES # MEXICO BAJA CAL N OF SINALOA AND SONORA) ! # MEXICO BAJA CAL N 8 H BEHIND UTC ABOVE 28TH PARALLAL APR 3 # MEXICO BAJA CAL N - OCT 29 ! # MEXICO BAJA CAL N 7 H BEHIND UTC ABOVE 28TH PARALLAL APR 3 # MEXICO BAJA CAL N - 0CT 29 # MEXICO 6 H BEHIND UTC STATES OF DURANGO, # MEXICO COAHUILA, NUEVO LEON, --- 920,928 ---- # MEXICO BAJA CAL N 7 H BEHIND UTC BAJA CALIFORNIA SUR AND # MEXICO BAJA CAL N N. PACIFIC COAST (STATES # MEXICO BAJA CAL N OF SINALOA AND SONORA) ! # MEXICO BAJA CAL N 8 H BEHIND UTC ABOVE 28TH PARALLEL APR 3 # MEXICO BAJA CAL N - OCT 29 ! # MEXICO BAJA CAL N 7 H BEHIND UTC ABOVE 28TH PARALLEL APR 3 # MEXICO BAJA CAL N - 0CT 29 # MEXICO 6 H BEHIND UTC STATES OF DURANGO, # MEXICO COAHUILA, NUEVO LEON, =================================================================== RCS file: RCS/southamerica,v retrieving revision 1996.13 retrieving revision 1996.13.1.1 diff -c -r1996.13 -r1996.13.1.1 *** southamerica 1996/11/24 01:07:37 1996.13 --- southamerica 1996/12/18 06:42:29 1996.13.1.1 *************** *** 61,67 **** # ARGENTINA 3 H BEHIND UTC # From Hernan G. Otero <hernan(a)isoft.com.ar> (1995-06-26): ! # I am sending modifications to the Argentinian time zone table... # AR was chosen because they are the ISO letters that represent Argentina. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S --- 61,67 ---- # ARGENTINA 3 H BEHIND UTC # From Hernan G. Otero <hernan(a)isoft.com.ar> (1995-06-26): ! # I am sending modifications to the Argentine time zone table... # AR was chosen because they are the ISO letters that represent Argentina. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S *************** *** 99,105 **** # These corrections were contributed by InterSoft Argentina S.A., # obtaining the data from the: # Talleres de Hidrografia Naval Argentina ! # (Argentinian Naval Hydrography Institute) # # Shanks gives 1989 Mar 16 and stops after 1990 Mar 4; go with Otero. Rule Arg 1989 1993 - Mar Sun>=1 0:00 0 - --- 99,105 ---- # These corrections were contributed by InterSoft Argentina S.A., # obtaining the data from the: # Talleres de Hidrografia Naval Argentina ! # (Argentine Naval Hydrography Institute) # # Shanks gives 1989 Mar 16 and stops after 1990 Mar 4; go with Otero. Rule Arg 1989 1993 - Mar Sun>=1 0:00 0 -

1 0