- tz - lists.iana.org

tzcode1997f.tar.gz and tadata1997g.tar.gz
by ado July 19, 1997

July 19, 1997

The files ftp://elsie.nci.nih.gov/pub/tzcode1997f.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1997g.tar.gz are now available. These incorporate Paul Eggert's updates circulated on the time zone list earlier this week; there's also a small change to a function prototype; "Music" has been renamed "Arts.htm", htmlified, and augmented to include information on Around the World in Eighty Days. --ado

1 0

proposed tz patches for Albania, Belgium, Congo, Hong Kong, and WWW
by Paul Eggert July 16, 1997

July 16, 1997

Here are some proposed patches to the tz database, notably to bring it up to date with recent political events: * Hong Kong is now part of China, and Zaire has been renamed Democratic Republic of Congo. These changes don't affect most programs; they just change commentary and tables accessed by tzselect. * Correct the DST changeover times in Albania from 1985 through 1990, as reported in the new edition of Shanks. (Expect more corrections in the future; I haven't had time to read Shanks's new edition past the A's yet.) * Correct several errors in the Belgian entries before 1944. Thanks to Pascal Delmoitie <pascal(a)belnet.be> for the new data. * Add Eric Ulevik <eau(a)ozemail.com.au>'s comments about NSW's plans to change clocks for the 2000 Olympics. * Rework WWW.htm to be more HTML-friendly. Add several sites, and update some obsolete references. Also, it'd be nice if WWW.htm could be available as a separate file; this would make it easier to give a URL to people interested in tz data. =================================================================== RCS file: RCS/WWW.htm,v retrieving revision 1997.5 retrieving revision 1997.5.1.3 diff -c -r1997.5 -r1997.5.1.3 *** WWW.htm 1997/05/03 22:52:34 1997.5 --- WWW.htm 1997/07/16 13:09:11 1997.5.1.3 *************** *** 2,109 **** <HTML> <HEAD> <TITLE> ! Sources for Time Zone and Daylight Savings Data </TITLE> </HEAD> <BODY> ! <PRE> ! # '@(#)WWW.htm 7.7' ! ! # From Paul Eggert <eggert(a)twinsun.com> (1997-03-28) ! # ! # The Web has several other sources for time zone and daylight savings data. ! # Here are some recent links that may be of interest. ! # ! # Date and Time Gateway ! # <A HREF="http://www.bsdi.com/date">http://www.bsdi.com/date</A> ! # A text-based source for tables of current time throughout the world. ! # Its point-and-click interface accesses a recent version of the tz data. ! # ! # WORLDTIME: interactive atlas, time info, public holidays ! # <A HREF="http://www.worldtime.com/">http://www.worldtime.com/</A> ! # Interactive world atlas with information on local time, sunrise and sunset, ! # and public holidays in several hundred cities around the world. ! # ! # Local Times Around the World ! # <A HREF="http://www.hilink.com.au/times/">http://www.hilink.com.au/times/</A> ! # This text-based system contains links to local time servers ! # throughout the world, and though the coverage is limited, ! # the live data provide a nice way to check one's tables. ! # ! # World Time Zones ! # <A HREF="http://tycho.usno.navy.mil/tzones.html">http://tycho.usno.navy.mil/tzones.html</A> ! # US Naval Observatory data, used as the source for the usno* files. ! # ! # Standard Time Zones of the World ! # <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-gif/802483.gif">http://www.odci.gov/cia/publications/nsolo/rmap-gif/802483.gif</A> [75 kB] ! # <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-tif/802483.tif">http://www.odci.gov/cia/publications/nsolo/rmap-tif/802483.tif</A> [1 MB] ! # <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-pdf/802483.pdf">http://www.odci.gov/cia/publications/nsolo/rmap-pdf/802483.pdf</A> [3 MB] ! # A static time zone map, available in multiple resolutions. ! # The quality is good, but the map does not indicate summer time, ! # and parts of the data are a few years out of date. ! # ! # Detailed World Clock information ! # <A HREF="http://www.stud.unit.no/USERBIN/steffent/timezones.pl">http://www.stud.unit.no/USERBIN/steffent/timezones.pl</A> ! # A map of cities and a list of UTC offsets and current DST rules in each city. ! # ! # The Time of Internet ! # <A HREF="http://pisolo.cstv.to.cnr.it/toi/uk/toi.html">http://pisolo.cstv.to.cnr.it/toi/uk/toi.html</A> ! # Good descriptions of Time Zones and daylight savings time, with diagrams. ! # The time zone map is out of date, however. ! # ! # A Few Facts Concerning RGO, GMT, and UT, by Richard B. Langley ! # <A HREF="http://community.bellcore.com/mbr/gmt-explained.html">http://community.bellcore.com/mbr/gmt-explained.html</A> ! # This answers questions like ``What is the difference between GMT and UTC?'' ! # ! # Daylight Saving Time -- Saving Time, Saving Energy ! # <A HREF="http://www.energy.ca.gov/energy/daylightsaving.html">http://www.energy.ca.gov/energy/daylightsaving.html</A> ! # A history of DST in the US. ! # ! # Yahoo! - Science:Weights and Measures:Measurements:Time:Daylight Savings Time ! # <A HREF="http://www.yahoo.com/Science/Weights_and_Measures/Measurements/Time/Dayligh…">http://www.yahoo.com/Science/Weights_and_Measures/Measurements/Time/Dayligh…</A> ! # The famous Internet indexing service Yahoo! collects its time zone info here. ! # ! # International Air Transport Association ! # <A HREF="http://www.iata.org/">http://www.iata.org/</A> ! # The source for the IATA SSIM, which gives current time zone rules for ! # all the airports served by commercial aviation. ! # ! ############################################################################### ! ! # From Manavendra Thakur <Manavendra_Thakur(a)NeXT.COM> (1995-11-06) ! # ! # To Paul's list of time zone information on the web, I would add the ! # following URL: ! # <A HREF="http://www.dhl.com/dhl/dhlinfo/1bb.html">http://www.dhl.com/dhl/dhlinfo/1bb.html</A> ! # or more simply: ! # <A HREF="http://www.dhl.com/">http://www.dhl.com/</A> ! # ! # This is run by DHL (the courier company), and it presents a list of the ! # countries served by that company. If you then click on a particular ! # country, here's an example of what you'll see (graphics stripped out): ! # ! # United Kingdom ! # ! # HOLIDAYS: Jan 1, 2, Apr 14, 17, May 1, 29, Aug 28, Dec 25, 26 ! # ! # INTERNATIONAL DIALING CODE: +44 ! # ! # CURRENT LOCAL TIME: 09:41 Monday 6 November 1995 ! # ! # I find this rather handy, and given that DHL covers 217 countries and ! # territories, it's pretty comprehensive coverage. ! # ! # (I have no idea what system DHL is using to calculate the local time, but ! # it's been accurate so far.) ! ! ############################################################################### ! ! ! # From Arthur David Olson <arthur_david_olson(a)nih.gov> (1996-01-04) ! # ! # A good source of information about ISO 8601 seems to be ! # <A HREF="http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html">http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html</A> ! # maintained by Markus Kuhn. ! </PRE> </BODY> </HTML> --- 2,109 ---- <HTML> <HEAD> <TITLE> ! Sources for Time Zone and Daylight Saving Time Data </TITLE> </HEAD> <BODY> ! <H1>Sources for Time Zone and Daylight Saving Time Data</H1> ! <P> ! <small> ! @(#)WWW.htm 7.7 ! </small> ! </P> ! <H2>Paul Eggert writes:</H2><P> ! The public-domain tz database contains code and data ! that represent the history of local time ! for many representative locations around the globe. ! It is updated periodically to reflect changes made by political bodies ! to UTC offsets and daylight-saving rules. ! This database (often called <samp>zoneinfo</samp>) ! is used by several implementations, ! including BSD, DJGPP, GNU/Linux, Irix, Solaris, and Unixware. ! In the tz database's ! <A HREF="ftp://elsie.nci.nih.gov/pub/">FTP distribution</A>, ! the code is in the file <samp>tzcode<var>C</var>.tar.gz</samp>, ! where <samp><var>C</var></samp> is the code's version; ! similarly, the data are in <samp>tzdata<var>D</var>.tar.gz</samp>, ! where <samp><var>D</var></samp> is the data's version. ! <P> ! The Web has several other sources for time zone and daylight saving time data. ! Here are some recent links that may be of interest. ! <UL> ! <LI><A HREF="http://www.bsdi.com/date">Date and Time Gateway</A> ! is a text-based source for tables of current time throughout the world. ! Its point-and-click interface accesses a recent version of the tz data. ! <LI><A HREF="http://www.worldtime.com/">WORLDTIME: interactive atlas, ! time info, public holidays</A> ! contains information on local time, sunrise and sunset, ! and public holidays in several hundred cities around the world. ! <LI><A HREF="http://www.hilink.com.au/times/">Local Times Around the World</A> ! is a text-based system containing links to local time servers ! throughout the world; though the coverage is limited, ! the live data provide a nice way to check one's tables. ! <LI><A HREF="http://tycho.usno.navy.mil/tzones.html">World Time Zones</A> ! contains US Naval Observatory data, used as the source ! for the <samp>usno*</samp> files. ! <LI>The US Central Intelligence agency publishes a static ! Standard Time Zones of the World map in multiple resolutions. ! including ! <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-gif/802483.gif">75 ! kB</A>, ! <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-tif/802483.tif">1 ! MB</A>, and ! <A HREF="http://www.odci.gov/cia/publications/nsolo/rmap-pdf/802483.pdf">3 ! MB</A> versions. ! The pictorial quality is good, but the map does not indicate summer time, ! and parts of the data are a few years out of date. ! <LI><A HREF="http://pisolo.cstv.to.cnr.it/toi/uk/toi.html">The ! Time of Internet</A> ! contains good descriptions of Time Zones and daylight saving time, ! with diagrams. ! The time zone map is out of date, however. ! <LI><A HREF="http://community.bellcore.com/mbr/gmt-explained.html">A Few Facts ! Concerning RGO, GMT, and UT, by Richard B. Langley</A> ! answers questions like ``What is the difference between GMT and UTC?'' ! <LI><A HREF="http://www.energy.ca.gov/energy/daylightsaving.html">Daylight ! Saving Time -- Saving Time, Saving Energy</A> ! is a history of DST in the US. ! <LI><A HREF="http://www.yahoo.com/Science/Weights_and_Measures/Measurements/Time/Dayligh…">Yahoo! - Science:Weights and Measures:Measurements:Time:Daylight Saving Time</A> ! is where the famous Internet indexing service Yahoo! collects its time zone ! info. ! <LI>The <A HREF="http://www.iata.org/">International Air Transport Association</A> ! publishes the IATA SSIM, which gives current time zone rules for ! all the airports served by commercial aviation. ! <LI><A HREF="http://hpiers.obspm.fr/webiers/results/bul/README.html"> ! Bulletins of IERS</A> contains official publications of the ! International Earth Rotation Service, the committee that decides ! when leap seconds occur. ! </UL> ! -- <A HREF="mailto:eggert@twinsun.com">eggert(a)twinsun.com</A> ! (1997-07-16) ! </P> ! <H2>Arthur David Olson writes:</H2><P> ! A good source of information about ISO 8601 seems to be ! <A HREF="http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html">International ! Standard Date and Time Notation</A> ! maintained by Markus Kuhn. ! <P> ! -- <A HREF="mailto:arthur_david_olson@nih.gov">arthur_david_olson(a)nih.gov</A> ! (1996-01-04) ! </P> ! <H2>Manavendra Thakur writes:</H2><P> ! <A HREF="http://www.dhl.com/dhl/dhlinfo/1bb.html">DHL Information</A> ! is run by <A HREF="http://www.dhl.com/">DHL</A> ! (the courier company), and it presents a list of the ! countries served by that company.... ! Here's an example of what you'll see for the ! <A HREF="http://www.dhl.com/dhlinfo/country/unitedki.html">United Kingdom</A>. ! I find this rather handy, and given that DHL covers 217 countries and ! territories, it's pretty comprehensive coverage. ! (I have no idea what system DHL is using to calculate the local time, but ! it's been accurate so far.) ! <P> ! -- <A HREF="mailto:Manavendra_Thakur@NeXT.COM">Manavendra_Thakur(a)NeXT.COM</A> ! (1995-11-06) ! </P> </BODY> </HTML> =================================================================== RCS file: RCS/africa,v retrieving revision 1997.5 retrieving revision 1997.5.1.1 diff -c -r1997.5 -r1997.5.1.1 *** africa 1997/03/29 17:48:49 1997.5 --- africa 1997/07/06 07:19:55 1997.5.1.1 *************** *** 218,224 **** Zone Indian/Comoro 2:53:04 - LMT 1911 Jul # Moroni, Gran Comoro 3:00 - EAT ! # Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Brazzaville 1:01:08 - LMT 1912 1:00 - CAT --- 218,231 ---- Zone Indian/Comoro 2:53:04 - LMT 1911 Jul # Moroni, Gran Comoro 3:00 - EAT ! # Democratic Republic of Congo ! # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Africa/Kinshasa 1:01:12 - LMT 1897 Nov 9 ! 1:00 - CAT ! Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 ! 2:00 - SAT ! ! # Republic of the Congo # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Brazzaville 1:01:08 - LMT 1912 1:00 - CAT *************** *** 656,668 **** 2:45 - BEAT 1957 3:00 - EAT - # Zaire - # Zone NAME GMTOFF RULES FORMAT [UNTIL] - Zone Africa/Kinshasa 1:01:12 - LMT 1897 Nov 9 - 1:00 - CAT - Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 - 2:00 - SAT - # Zambia # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Lusaka 1:53:08 - LMT 1903 Mar --- 663,668 ---- =================================================================== RCS file: RCS/asia,v retrieving revision 1997.5 retrieving revision 1997.5.1.1 diff -c -r1997.5 -r1997.5.1.1 *** asia 1997/03/29 17:48:50 1997.5 --- asia 1997/07/06 07:19:55 1997.5.1.1 *************** *** 214,241 **** 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May 8:00 PRC C%sT - - ############################################################################### - - # Republic of China - - # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S - Rule Taiwan 1945 1951 - May 1 0:00 1:00 D - Rule Taiwan 1945 1951 - Oct 1 0:00 0 S - Rule Taiwan 1952 only - Mar 1 0:00 1:00 D - Rule Taiwan 1952 1954 - Nov 1 0:00 0 S - Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D - Rule Taiwan 1955 1961 - Oct 1 0:00 0 S - Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D - Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D - Rule Taiwan 1974 1975 - Oct 1 0:00 0 S - Rule Taiwan 1980 only - Jun 30 0:00 1:00 D - Rule Taiwan 1980 only - Sep 30 0:00 0 S - # Zone NAME GMTOFF RULES FORMAT [UNTIL] - Zone Asia/Taipei 8:06:00 - LMT 1896 - 8:00 Taiwan C%sT - - ############################################################################### # Hong Kong # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule HK 1946 only - Apr 20 3:30 1:00 S --- 214,219 ---- *************** *** 258,263 **** --- 236,262 ---- 8:00 HK HK%sT 1997 Jul 1 # return to China 8:00 PRC C%sT + + ############################################################################### + + # Republic of China + + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S + Rule Taiwan 1945 1951 - May 1 0:00 1:00 D + Rule Taiwan 1945 1951 - Oct 1 0:00 0 S + Rule Taiwan 1952 only - Mar 1 0:00 1:00 D + Rule Taiwan 1952 1954 - Nov 1 0:00 0 S + Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D + Rule Taiwan 1955 1961 - Oct 1 0:00 0 S + Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D + Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D + Rule Taiwan 1974 1975 - Oct 1 0:00 0 S + Rule Taiwan 1980 only - Jun 30 0:00 1:00 D + Rule Taiwan 1980 only - Sep 30 0:00 0 S + # Zone NAME GMTOFF RULES FORMAT [UNTIL] + Zone Asia/Taipei 8:06:00 - LMT 1896 + 8:00 Taiwan C%sT + # Macao # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Macao 1961 1962 - Mar Sun>=16 3:30 1:00 S =================================================================== RCS file: RCS/australasia,v retrieving revision 1997.5 retrieving revision 1997.5.1.1 diff -c -r1997.5 -r1997.5.1.1 *** australasia 1997/03/29 17:48:50 1997.5 --- australasia 1997/07/06 07:19:55 1997.5.1.1 *************** *** 768,773 **** --- 768,779 ---- # Prem Bob Carr announced NSW will fall into line with other E states # and SA and continue daylight savings to the last Sun in Mar. + # From Eric Ulevik <eau(a)ozemail.com.au> (1997-06-12): + # The NSW state government in Australia is talking about bringing the start + # of daylight savings time forward in the year 2000 to cater for the Olympics. + # This is going to take some time to be negotiated, because the plan is to do + # this in multiple states due to soccer games (which are not just in Sydney). + # Yancowinna # From John Basser (1989-01-04): =================================================================== RCS file: RCS/europe,v retrieving revision 1997.6 retrieving revision 1997.6.1.1 diff -c -r1997.6 -r1997.6.1.1 *** europe 1997/05/03 22:52:28 1997.6 --- europe 1997/07/06 07:19:55 1997.6.1.1 *************** *** 829,835 **** Rule C-Eur 1917 1918 - Apr Mon>=15 2:00s 1:00 S Rule C-Eur 1917 1918 - Sep Mon>=15 2:00s 0 - Rule C-Eur 1940 only - Apr 1 2:00s 1:00 S - # Whitman says 1941 DST was only from Feb 25 to Oct 5; go with Shanks. Rule C-Eur 1942 only - Nov 2 2:00s 0 - Rule C-Eur 1943 only - Mar 29 2:00s 1:00 S Rule C-Eur 1943 only - Oct 4 2:00s 0 - --- 829,834 ---- *************** *** 938,949 **** Rule Albania 1983 only - Apr 18 0:00 1:00 S Rule Albania 1983 only - Oct 1 0:00 0 - Rule Albania 1984 only - Apr 1 0:00 1:00 S - Rule Albania 1984 only - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tirane 1:19:20 - LMT 1914 1:00 - CET 1940 Jun 16 ! 1:00 Albania CE%sT 1985 Mar 31 1:00 ! 1:00 W-Eur CE%sT 1991 1:00 EU CE%sT # Andorra --- 937,947 ---- Rule Albania 1983 only - Apr 18 0:00 1:00 S Rule Albania 1983 only - Oct 1 0:00 0 - Rule Albania 1984 only - Apr 1 0:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tirane 1:19:20 - LMT 1914 1:00 - CET 1940 Jun 16 ! # The following transition is from Shanks's 4th edition (1995). ! 1:00 Albania CE%sT 1984 Jul 1:00 EU CE%sT # Andorra *************** *** 984,1033 **** 2:00 Russia EE%sT # Belgium ! # Whitman and Shanks disagree; go with Shanks, usually. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! # From Whitman: Rule Belgium 1919 only - Mar 1 23:00s 1:00 S ! Rule Belgium 1919 only - Oct 4 23:00s 0 - ! # Shanks gives 1920 Feb 14 23:00s; go with Whitman. ! Rule Belgium 1920 1921 - Mar 14 23:00s 1:00 S Rule Belgium 1920 only - Oct 23 23:00s 0 - Rule Belgium 1921 only - Oct 25 23:00s 0 - Rule Belgium 1922 only - Mar 25 23:00s 1:00 S ! # Whitman gives 1927 Oct 1 2:00s and 1928 Oct 7 2:00s; go with Shanks. ! Rule Belgium 1922 1928 - Oct Sat>=1 23:00s 0 - Rule Belgium 1923 only - Apr 21 23:00s 1:00 S Rule Belgium 1924 only - Mar 29 23:00s 1:00 S Rule Belgium 1925 only - Apr 4 23:00s 1:00 S Rule Belgium 1926 only - Apr 17 23:00s 1:00 S Rule Belgium 1927 only - Apr 9 23:00s 1:00 S Rule Belgium 1928 only - Apr 14 23:00s 1:00 S Rule Belgium 1929 only - Apr 21 2:00s 1:00 S - Rule Belgium 1929 1938 - Oct Sun>=2 2:00s 0 - Rule Belgium 1930 only - Apr 13 2:00s 1:00 S Rule Belgium 1931 only - Apr 19 2:00s 1:00 S ! Rule Belgium 1932 only - Apr 17 2:00s 1:00 S Rule Belgium 1933 only - Mar 26 2:00s 1:00 S Rule Belgium 1934 only - Apr 8 2:00s 1:00 S Rule Belgium 1935 only - Mar 31 2:00s 1:00 S Rule Belgium 1936 only - Apr 19 2:00s 1:00 S - # Whitman says 1937 Apr 18 2:00s; go with Shanks. Rule Belgium 1937 only - Apr 4 2:00s 1:00 S - # Whitman says 1938 Apr 10 2:00s; go with Shanks. Rule Belgium 1938 only - Mar 27 2:00s 1:00 S Rule Belgium 1939 only - Apr 16 2:00s 1:00 S Rule Belgium 1939 only - Nov 19 2:00s 0 - Rule Belgium 1945 only - Apr 2 2:00s 1:00 S Rule Belgium 1945 only - Sep 16 2:00s 0 - Rule Belgium 1946 only - May 19 2:00s 1:00 S Rule Belgium 1946 only - Oct 7 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Brussels 0:17:20 - LMT 1880 ! 0:17:20 - BMT 1892 May 1 12:00 # Brussels MT ! 0:00 - WET 1914 Aug 4 ! 1:00 C-Eur CE%sT 1919 Mar 1 23:00 ! 0:00 Belgium WE%sT 1940 Feb 24 23:00 ! 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Belgium CE%sT 1977 1:00 EU CE%sT --- 982,1043 ---- 2:00 Russia EE%sT # Belgium ! # ! # From Paul Eggert (1997-07-02): ! # Entries from 1918 through 1991 are taken from: ! # Annuaire de L'Observatoire Royal de Belgique, ! # Avenue Circulaire, 3, B-1180 BRUXELLES, CLVIIe annee, 1991 ! # (Imprimerie HAYEZ, s.p.r.l., Rue Fin, 4, 1080 BRUXELLES, MCMXC), ! # pp 8-9. ! # LMT before 1892 was 0:17:30, according to the official journal of Belgium: ! # Moniteur Belge, Samedi 30 Avril 1892, N.121. ! # Thanks to Pascal Delmoitie <pascal(a)belnet.be> for these references. ! # The 1918 rules are listed for completeness; they apply to unoccupied Belgium. ! # Assume Brussels switched to WET in 1918 when the armistice took effect. ! # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! Rule Belgium 1918 only - Mar 9 0:00s 1:00 S ! Rule Belgium 1918 1919 - Oct Sat>=1 23:00s 0 - Rule Belgium 1919 only - Mar 1 23:00s 1:00 S ! Rule Belgium 1920 only - Feb 14 23:00s 1:00 S Rule Belgium 1920 only - Oct 23 23:00s 0 - + Rule Belgium 1921 only - Mar 14 23:00s 1:00 S Rule Belgium 1921 only - Oct 25 23:00s 0 - Rule Belgium 1922 only - Mar 25 23:00s 1:00 S ! Rule Belgium 1922 1927 - Oct Sat>=1 23:00s 0 - Rule Belgium 1923 only - Apr 21 23:00s 1:00 S Rule Belgium 1924 only - Mar 29 23:00s 1:00 S Rule Belgium 1925 only - Apr 4 23:00s 1:00 S Rule Belgium 1926 only - Apr 17 23:00s 1:00 S Rule Belgium 1927 only - Apr 9 23:00s 1:00 S Rule Belgium 1928 only - Apr 14 23:00s 1:00 S + Rule Belgium 1928 1938 - Oct Sun>=2 2:00s 0 - Rule Belgium 1929 only - Apr 21 2:00s 1:00 S Rule Belgium 1930 only - Apr 13 2:00s 1:00 S Rule Belgium 1931 only - Apr 19 2:00s 1:00 S ! Rule Belgium 1932 only - Apr 3 2:00s 1:00 S Rule Belgium 1933 only - Mar 26 2:00s 1:00 S Rule Belgium 1934 only - Apr 8 2:00s 1:00 S Rule Belgium 1935 only - Mar 31 2:00s 1:00 S Rule Belgium 1936 only - Apr 19 2:00s 1:00 S Rule Belgium 1937 only - Apr 4 2:00s 1:00 S Rule Belgium 1938 only - Mar 27 2:00s 1:00 S Rule Belgium 1939 only - Apr 16 2:00s 1:00 S Rule Belgium 1939 only - Nov 19 2:00s 0 - + Rule Belgium 1940 only - Feb 25 2:00s 1:00 S + Rule Belgium 1944 only - Sep 17 2:00s 0 - Rule Belgium 1945 only - Apr 2 2:00s 1:00 S Rule Belgium 1945 only - Sep 16 2:00s 0 - Rule Belgium 1946 only - May 19 2:00s 1:00 S Rule Belgium 1946 only - Oct 7 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] ! Zone Europe/Brussels 0:17:30 - LMT 1880 ! 0:17:30 - BMT 1892 May 1 12:00 # Brussels MT ! 0:00 - WET 1914 Nov 8 ! 1:00 - CET 1916 May 1 0:00 ! 1:00 C-Eur CE%sT 1918 Nov 11 11:00u ! 0:00 Belgium WE%sT 1940 May 20 2:00s ! 1:00 C-Eur CE%sT 1944 Sep 3 1:00 Belgium CE%sT 1977 1:00 EU CE%sT =================================================================== RCS file: RCS/iso3166.tab,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** iso3166.tab 1996/09/03 23:48:46 1.1 --- iso3166.tab 1997/07/06 07:19:55 1.2 *************** *** 51,58 **** BZ Belize CA Canada CC Cocos (Keeling) Islands CF Central African Rep. ! CG Congo CH Switzerland CI Cote d'Ivoire CK Cook Islands --- 51,59 ---- BZ Belize CA Canada CC Cocos (Keeling) Islands + CD Congo (Dem. Rep.) CF Central African Rep. ! CG Congo (Rep.) CH Switzerland CI Cote d'Ivoire CK Cook Islands *************** *** 103,109 **** GU Guam GW Guinea-Bissau GY Guyana - HK Hong Kong HM Heard Island & McDonald Islands HN Honduras HR Croatia --- 104,109 ---- *************** *** 250,254 **** YU Yugoslavia ZA South Africa ZM Zambia - ZR Zaire ZW Zimbabwe --- 250,253 ---- =================================================================== RCS file: RCS/zone.tab,v retrieving revision 1.2.1.2 retrieving revision 1.2.1.4 diff -c -r1.2.1.2 -r1.2.1.4 *** zone.tab 1997/02/27 21:11:39 1.2.1.2 --- zone.tab 1997/07/16 16:25:51 1.2.1.4 *************** *** 101,106 **** --- 101,108 ---- CA +6043-13503 America/Whitehorse Pacific Time - south Yukon CA +6404-13925 America/Dawson Pacific Time - north Yukon CC -1210+09655 Indian/Cocos + CD -0418+01518 Africa/Kinshasa west Dem. Rep. of Congo + CD -1140+02728 Africa/Lubumbashi east Dem. Rep. of Congo CF +0422+01835 Africa/Bangui CG -0416+01517 Africa/Brazzaville CH +4723+00832 Europe/Zurich *************** *** 111,116 **** --- 113,119 ---- CM +0403+00942 Africa/Douala CN +4545+12641 Asia/Harbin north Manchuria CN +3114+12128 Asia/Shanghai China coast + CN +2217+11409 Asia/Hong_Kong Hong Kong CN +2934+10635 Asia/Chungking China mountains CN +4348+08735 Asia/Urumqi Tibet & Xinjiang CN +3929+07559 Asia/Kashgar Eastern Turkestan *************** *** 167,173 **** GU +1328+14445 Pacific/Guam GW +1151-01535 Africa/Bissau GY +0648-05810 America/Guyana - HK +2217+11409 Asia/Hong_Kong HN +1406-08713 America/Tegucigalpa HR +4548+01558 Europe/Zagreb HT +1832-07220 America/Port-au-Prince --- 170,175 ---- *************** *** 366,371 **** YU +4450+02030 Europe/Belgrade ZA -2615+02800 Africa/Johannesburg ZM -1525+02817 Africa/Lusaka - ZR -0418+01518 Africa/Kinshasa west Zaire - ZR -1140+02728 Africa/Lubumbashi east Zaire ZW -1750+03103 Africa/Harare --- 368,371 ----

1 0

ISO 8601 v2
by kuhn＠cs.purdue.edu July 14, 1997

July 14, 1997

I have just received a copy of the document ISO/TC 154/WG 8601/101 "Proposal for ISO 8601 - version 2", 1996-05-02, from the Nederlands Normalisatie-instituut (NNI). Here is a very brief summary of the suggested changes: - a new section explaining the difference between "time-point" and "period (time-interval)", as well as "duration". "This standard does not specify what entities should be considered time-points and what entities may be periods or time-intervals. The decision, whether for instance 'April 1985' specifies a time point or a time-interval is left to the users of the information (because this decision depends upon its use.)". - The units of time used and the zero-points of counting schemes are now explicitely defined: - second: as in ISO 31-1 - minute: time intervall of 60 seconds - hour: 60 minutes - day: 24 hours - week: 7 days - month: approx. 30 days - year: 12 consecutive months, considerd to approximate the time-interval required for one revolution of the earth around the sun "The Gregorian calendar uses a starting point which assigns the year number 1875 to the year in which the Convention du Metre was signed at Paris. All years numbered according to this convention have, by definition, one specific (calendar) year number. [...]" Ok, so definitely no Julian calendar, but still no word about years before 0001. The lengths of the 12 months are now listed, together with the day of year numers that every months covers in a leap or non-leap year. - ISO/TC 154 has received a number of suggestions to improve the Gregorian calendar in both the lengths of months as well as the location and occurance of leap days. "However, ISO/TC 154 does not feel qualified to propose a reorganization of the Gregorian calendar." (I guess the world has already enough problems with the year 2000, and considering the huge investment in almost unchangeable computer software, a calendar reforms today seems extremely unlikely.) - the ---D format has been removed. - the proposal explicitely does not address leap seconds, the allowed second range is still 00 to 59 :-( - the ugly T is still there, although France has critisised this separator and the whole idea of considering date and time and time zone to be separate fields. - There is a new annex C "temporal relationships", which defines 13 terms in order to represent the temporal relationship of an event with a time-period. This was copied from a CEN Medical Informatics working group proposal. (Make sure you use a monospaced font to display the following!) Reference time interval: ----------------> AT ----------------> BEFORE -------> AFTER -------> DURING -----> INCLUDES ----------------------------------------> CO-CONTINUES ---------------------------> CO-PRECEDES -----------------------------> CO-STARTS ----------> CO-ENDS -----------> WARNING: This was an incomplete summary of a 14 page document, which is only a first draft that is expected to be superceeded by a second draft in a few weeks. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

Another ISO 8601:1998 Brainstorm
by kuhn＠cs.purdue.edu July 12, 1997

July 12, 1997

While I am waiting to receive the 1996 ISO 8601 revision proposal, here one further idea: allow a 0 value to mean "not known" in all the date notations, i.e. in a fixed width format, 1997-07 could also be stored as 1997-07-00. I have seen this technique used in at least one database so far (DIN's PERINORM). A silly question from a non-native English speaker: what is the difference between "not known" and "not specified"? There are codes for both situations defined in ISO 5218 and I never understood, why. See <ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO-5218-summary> for the full text of this standard. What about 1492J-09-31 refering to a date in the Julian calendar and B0345J-02-13 refering to February 2, 345 B.C.E. in the Julian calendar? I guess, no matter what we do with negative years, lexical sorting and comparing will always be messed up. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

suggested improvements for C9x `New formats for strftime()' (N733)
by Paul Eggert July 9, 1997

July 9, 1997

You propose new conversion specifiers for strftime in C9x, the new C standard, in your document ISO/IEC JTC1/SC22/WG14 N733 <http://www.gold.net/users/cdwf/c/wg14n733.txt> (1997-07-01). Here are a couple of quotes from that document, followed by some suggestions for improvements. %f is replaced by the weekday as a decimal number (1-7), where Monday is 1 (the ISO 8601 weekday number). Please change this from %f to %u, because %u is current practice. I believe %u was introduced several years ago in Arnold Robbins's public domain strftime, and it is now the standard in many strftime implementations, including the Arthur David Olson public domain strftime <ftp://elsie.nci.nih.gov/pub/>, the GNU C library <ftp://prep.ai.mit.edu/pub/gnu/>, 4.4BSD (e.g. BSD/OS), Linux, and Solaris. %u is also required by POSIX.2's `date' command to have the same meaning (please see IEEE Std 1003.2-1992 section 4.15.4.1 page 241 line 2931); it would be odd for C9x to diverge unnecessarily from POSIX in this respect. %V is replaced by the ISO 8601 week number of the year %V does not suffice to support ISO 8601 week-oriented dates, because the ISO 8601 week's year may not be the same as the current year. For example, using ISO 8601 week notation, `1997-W01-2' denotes 1996-12-31 (as the first ISO week of 1997 begins on 1996-12-30). Similarly, `1998-W53-5' denotes 1999-01-01. If only %V is available, there's no easy way for a C program to output ISO-format dates like `1997-W01-2'. To work around this shortcoming, I propose that C9x add Robbins's %G and %g formats, as follows: %G is replaced by the year containing the ISO 8601 week %g is replaced by %G modulo 100 E.g. the format "%G-W%V-%u" outputs the ISO 8601 full week-oriented date, and the format "%gW%V%u" outputs the ISO 8601 format containing the week-oriented date without century or punctuation. %G and %g were introduced more recently by Robbins, and they are also current practice, though not as widespread as %u: they are supported by the Robbins and Olson public-domain implementations, the GNU C library, and Linux.

2 2

ISO 8601:1986 revision has started!
by kuhn＠cs.purdue.edu July 7, 1997

July 7, 1997

I just got an interesting reply from Mr. Louis Visser <Louis.Visser(a)nni.nl> on my question whether there is any work going on to revise ISO 8601 soon: ISO TC 154 decided in 1996 to revise ISO 8601. Four member bodies responded to the calls for participation in the WG preparing the revision: Sweden, Austria, Yugoslavia and the Netherlands. I am coordinating the work of the WG. A first proposal for the revision has been prepared late 1996; a second proposal is expected in a month time. Please take your copy of ISO 8601 and think about what you would like to see changed in the next revision of ISO 8601. Some topics I could think of that might be addressed in a revision are: - the "ugly T" (allow a space alternatively) - profiles for easy reference in other standards (which ones?) - BNF syntax description - replace many of the ---DD style notations by shorter ones - allow second 60 (leap second) - decimal fraction of a day (1997-100.5 is noon) - third sunday of February 1997 as 1997-02-3-7 ??? - years < 0001 and > 9999 (suggestions?) - add (modified) julian date notation - calendar indicator? - time zone rule descriptors? - sliding window interpretation of YY (Y2K)? - ... [I don't think each of them is a good idea, this list is just intended as a brain storming trigger to keep you thinking about alternatives.] May be, I'll start a Web page collecting ideas for improving ISO 8601. I hope, I can organize a copy of the existing revision proposal and make it somehow available online. I'd love to hear about any suggestions that you might have! Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn(a)cs.purdue.edu

1 0

Hong Kong
by Garrett Wollman June 30, 1997

June 30, 1997

Someone on the NTP newsgroup pointed out that China uses a single time zone for the entire country. Does anyone out there on this list know whether Hong Kong will be allowed to keep its current timezone after the takeover? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman(a)lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick

1 0

ISO 8601 and the horrible "T"
by Misha Wolf June 27, 1997

June 27, 1997

Stu Weibel has given me permission to quote from his private mail: > Where you have YYYY-MM-DDThh:mm-hh:mm, is it possible to interpose a > seperator other than T that makes it clearer to the human eye where > the date ends and Time begins? I suspect the answer to this is that > such a separator would knock the profile out of whack with 8601, but > I thought I'd ask anyhow. The "T" is, I think, the most despised aspect of the ISO 8601 standard but I think we're stuck with it. Some relevant quotes from the standard: [T] is used as a time designator to indicate the start of the representation of the time of day in combined date and time of day expressions; The space character shall not be used in the representations. The only suggestion I have seen for getting rid of the "T" is a kind of trick: We say that we are representing not a "combined date and time" but rather a separate date and a time. We then place them next to each other, separated by our favourite character. If "*" represents our favourite character, we get: 1994-11-05*08:15:30-05:00 instead of: 1994-11-05T08:15:30-05:00 The problem with this solution is precisely that it is a trick. In reality, we are dealing with a single date-with-time and it confuses things to pretend that we're not. Also, there must be lots of software out there which is ISO 8601-conformant and would choke on our favourite character. I suggest we decide that this stuff isn't primarily for human consumption and make use of it, warts and all. ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Atlantic Monthly coverage of 2000/2001
by ado June 26, 1997

June 26, 1997

See http://www.theatlantic.com/issues/97jul/preview.htm for a very brief blurb on the magazine's article entitled "Zero" regarding when the millenium comes; see the magazine itself for details. Your correspondent was disappointed that there was no replay of the joke from Saul Bass's film "Why Man Creates:" First cartoon charcter: I've discovered the zero. Second cartoon character: What? First cartoon character: Nothing, nothing. --ado

1 0

Re: Draft profile of ISO 8601
by Misha Wolf June 26, 1997

June 26, 1997

Pete Ciuffetti has given me permission to quote his private mail: > In your levels of granularity, what do you think about allowing year-only, > "YYYY" and year-month "YYYY-MM". This would help solve a need I perceive > in our database design at SilverPlatter. Most of our records are > bibliographic and they specify the date of publication for some described > item like a book or journal. Typically this is just a year, like "1997" or > it is a year and month, "Feb 1997", sometimes a day is specified. > > In my metadata, I'd like to store whatever granularity that makes sense for > the published item and I would like all the dates to conform to a standard. > But no standard seems to consider these broader levels of granularity. ISO 8601 does. I would be very happy to add these options to the profile. > Also, in these broad levels for comparison purposes, I suggest implied > values would be 01 for an unspecified month, and 01 for an unspecified day. For the moment, I have backed away from suggesting how dates of differing granularities be compared, as it is contentious. > Regards, > Pete Ciuffetti > SilverPlatter ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

Profile of ISO 8601 (draft) - RESEND
by Misha Wolf June 26, 1997

June 26, 1997

Please accept my apologies if you have seen this message. I originally sent it over 24 hours ago but have not seen it reflected back. As I don't know where the problem lies, I've decided to resend the message. ------------------------------------------------------------------------ Introduction ============ This note defines a profile of [ISO 8601], the International Standard for the representation of dates and times. A discussion of [ISO 8601] is available at [KUHN]. [ISO 8601] describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements. The profile may be adopted by standards which require an unambiguous representation of dates and times. As different standards have their own requirements regarding granularity and flexibility, this profile offers a number of options. An adopting standard must specify which of these options it permits. Summary ======= This profile of [ISO 8601] defines four levels of granularity: 1. Date only 2. Date plus hours and minutes 3. Date plus hours, minutes and seconds 4. Date plus hours, minutes, seconds and decimal fractions of a second An adopting standard must permit one or more of these options. This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC, with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. An adopting standard must permit one or both of these options, unless the standard does not permit granularity options 2, 3 and 4. This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited"), unless the standard does not permit granularity option 4. The formats =========== 1. Date only ------------- The format is: YYYY-MM-DD Example: 1994-11-05 This example corresponds to November 5, 1994. 2. Date plus hours and minutes ------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mmZ Example: 1994-11-05T13:15Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm+hh:mm or: YYYY-MM-DDThh:mm-hh:mm Example: 1994-11-05T08:15-05:00 Both the examples in this section correspond to November 5, 1994, 8:15 am, US Eastern Standard Time. 3. Date plus hours, minutes and seconds ---------------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ssZ Example: 1994-11-05T13:15:30Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss+hh:mm or: YYYY-MM-DDThh:mm:ss-hh:mm Example: 1994-11-05T08:15:30-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 4. Date plus hours, minutes, seconds and decimal fractions of a second ----------------------------------------------------------------------- The number of seconds is followed by a dot and one or more digits representing a decimal fraction of a second. An adopting standard must specify both the minimum and the maximum number of digits, as described earlier. If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ss.sZ Example: 1994-11-05T13:15:30.45Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss.s+hh:mm or: YYYY-MM-DDThh:mm:ss.s-hh:mm Example: 1994-11-05T08:15:30.45-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30.45 am, US Eastern Standard Time. References ========== [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

RE: Draft profile of ISO 8601
by Olson, Arthur David June 26, 1997

June 26, 1997

> Treatment of missing elements: > In some cases, software components may need to compare a date/time using > coarser granularity with one using finer granularity. [One option:] The missing > portions are deemed to be equal to zero. This is the approach now taken in the time zone information files. --ado

1 0

Profile of ISO 8601 (draft)
by Misha Wolf June 25, 1997

June 25, 1997

Introduction ============ This note defines a profile of [ISO 8601], the International Standard for the representation of dates and times. A discussion of [ISO 8601] is available at [KUHN]. [ISO 8601] describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a few date/time formats, likely to satisfy most requirements. The profile may be adopted by standards which require an unambiguous representation of dates and times. As different standards have their own requirements regarding granularity and flexibility, this profile offers a number of options. An adopting standard must specify which of these options it permits. Summary ======= This profile of [ISO 8601] defines four levels of granularity: 1. Date only 2. Date plus hours and minutes 3. Date plus hours, minutes and seconds 4. Date plus hours, minutes, seconds and decimal fractions of a second An adopting standard must permit one or more of these options. This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC, with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. An adopting standard must permit one or both of these options, unless the standard does not permit granularity options 2, 3 and 4. This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited"), unless the standard does not permit granularity option 4. The formats =========== 1. Date only ------------- The format is: YYYY-MM-DD Example: 1994-11-05 This example corresponds to November 5, 1994. 2. Date plus hours and minutes ------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mmZ Example: 1994-11-05T13:15Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm+hh:mm or: YYYY-MM-DDThh:mm-hh:mm Example: 1994-11-05T08:15-05:00 Both the examples in this section correspond to November 5, 1994, 8:15 am, US Eastern Standard Time. 3. Date plus hours, minutes and seconds ---------------------------------------- If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ssZ Example: 1994-11-05T13:15:30Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss+hh:mm or: YYYY-MM-DDThh:mm:ss-hh:mm Example: 1994-11-05T08:15:30-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 4. Date plus hours, minutes, seconds and decimal fractions of a second ----------------------------------------------------------------------- The number of seconds is followed by a dot and one or more digits representing a decimal fraction of a second. An adopting standard must specify both the minimum and the maximum number of digits, as described earlier. If times are expressed in UTC, the format is: YYYY-MM-DDThh:mm:ss.sZ Example: 1994-11-05T13:15:30.45Z If times are expressed in local time, together with a time zone offset, the format is: YYYY-MM-DDThh:mm:ss.s+hh:mm or: YYYY-MM-DDThh:mm:ss.s-hh:mm Example: 1994-11-05T08:15:30.45-05:00 Both the examples in this section correspond to November 5, 1994, 8:15:30.45 am, US Eastern Standard Time. References ========== [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ------------------------------------------------------------------------ Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

The Year 2000 Problem Listserv
by Monty Solomon June 25, 1997

June 25, 1997

Begin forwarded message: Date: Mon, 23 Jun 1997 23:16:12 -0700 From: Susan Evoy <sevoy(a)Sunnyside.COM> Subject: The Year 2000 Problem Listserv The Year 2000 problem is getting increasing attention and is a matter of growing concern in this country and abroad. There are forums for discussion of technical aspects of the problem but none that focus on the economic, social and political implications. If you would be interested in participating in a forum on the y2k (year two thousand) problem join the cpsr-2yk listserv! To subscribe to this list, you should send a message to listserv(a)cpsr.org In the body of the message, write: subscribe cpsr-y2k <firstname> <last name> Norman Kurland (kurlandn(a)crisny.org) will be the moderator of the list. Here is a possible opening question: What are the most critical economic, political and social consequences of the Year 2000 Problem? How should computer professionals be dealing with them? CPSR=Computer Professionals for Social Responsibility http://www.cpsr.org/dox/home.html cpsr(a)cpsr.org P.O. Box 717 Palo Alto, CA 94302 Phone: (415)322-3778 Fax: (415)322-4748

1 0

Re: Draft profile of ISO 8601
by Misha Wolf June 24, 1997

June 24, 1997

Dan Connolly wrote: > > Misha Wolf wrote: > > > 2. Date plus hours and minutes > > ------------------------------- > > > > The format is one of: YYYY-MM-DDThh:mmZ > > YYYY-MM-DDThh:mm+hh:mm > > YYYY-MM-DDThh:mm-hh:mm > > A major benefit of using YYYY-MM-DD over the Internet > traditional Tue, 30 Jan 1997... format is that string > comparisons work for date comparisons; e.g. you don't > have to go through heroics to sort log files by date. > > By including timezone stuff (+hh:mm), you lose that > benefit. > > Is there some motivation for including +yy:mm that > offsets this loss? [Note: For "+yy:mm" read "+hh:mm"] I'm not sure which of the following you are asking: Q1. Why have time zone info? Q2. Why not require that all dates/times be normalised to UTC when entered. Answer to Q1: A time is only meaningful within a time zone. Answers to Q2: a) I'm defining a profile with various options (this can be viewed as a family of profiles), such that each adopting standard can choose the appropriate options. For many purposes, the actual time zone is important. PICS, for instance, requires the time zone. b) The normalisation to UTC can easily be done prior to date/time collation/comparison. It involves just an addition or subtraction. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

Europe/Zurich
by Florian La Roche June 24, 1997

June 24, 1997

Why do you list Zurich for switzerland? (CH) The capital of the swiss is Bern. Thanks, Florian La Roche

1 0

Draft profile of ISO 8601
by Misha Wolf June 22, 1997

June 22, 1997

Though I have been reluctant to write a profile of [ISO 8601], the W3C HTML WG has decided it wants the spec for Cougar (the next version of HTML) to reference a date/time profile and I've been actioned to produce this profile by the end of next week. This note lists some preliminary thoughts for comment. If you want to find out more about [ISO 8601], visit [KUHN]. I wrote a few days ago that my goal is a profile which is: - conformant, - widely adopted, - easy to understand, - not too permissive, - not too restrictive, - electronically available. The way to reconcile some of these requirements is to provide a profile allowing several options, especially regarding granularity. Other standards could refer to the profile and state which option has/have been adopted. A rough sketch follows. I have borrowed some phrases from [KUHN]. Granularity =========== This profile of [ISO 8601] defines four levels of granularity: 1. Date only ------------- The format is: YYYY-MM-DD 2. Date plus hours and minutes ------------------------------- The format is one of: YYYY-MM-DDThh:mmZ YYYY-MM-DDThh:mm+hh:mm YYYY-MM-DDThh:mm-hh:mm where: Z indicates that the date/time uses Universal Time (UTC), +hh:mm indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC, -hh:mm indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. 3. Date plus hours, minutes and seconds ---------------------------------------- The format is one of: YYYY-MM-DDThh:mm:ssZ YYYY-MM-DDThh:mm:ss+hh:mm YYYY-MM-DDThh:mm:ss-hh:mm 4. Date plus hours, minutes, seconds and decimal fractions of seconds ---------------------------------------------------------------------- The format is one of those shown in option 3, with the insertion, immediately after "ss", of either a full stop or a comma, followed immediately by one or more digits representing a decimal fraction of a second, eg: YYYY-MM-DDThh:mm:ss.ddZ YYYY-MM-DDThh:mm:ss.dd+hh:mm YYYY-MM-DDThh:mm:ss.dd-hh:mm If adopting this granularity option, the adopting standard must state how many digits may be used to represent a decimal fraction of a second, eg: 2 digits, 1-3 digits, 1-99 digits, any number of digits. Treatment of missing elements ============================= In some cases, software components may need to compare a date/time using coarser granularity with one using finer granularity. This shall be done as described below. Granularity options 2-4 ----------------------- The missing portions are deemed to be equal to zero. Thus the following all represent the same date/time: 1997-06-20T12:34Z 1997-06-20T12:34:00Z 1997-06-20T12:34:00.00Z 1997-06-20T12:34:00.000000000000000000000000000Z Granularity option 1 -------------------- An isolated date is treated as if it had the following string appended: T12:00Z For example: 1997-06-20 is treated as if it were: 1997-06-20T12:00Z This approach, proposed by Charles Wicksteed, has the advantage that at 1997-06-20T12:00Z, most of the world would agree that the current date is 1997-06-20. Comments? ~~~ [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [KUHN] "A Summary of the International Standard Date and Time Notation", Markus Kuhn, <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>, 1996-11-05. [NEWMAN] "Date and Time on the Internet", Chris Newman, <draft-newman-datetime-01.txt>, January 1997. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Date/time on the Internet
by Misha Wolf June 18, 1997

June 18, 1997

Increasing numbers of Internet-related protocols and standards need to reference dates/times in a standard manner. The base standard mostly used for this purpose is [ISO 8601]. This agreement on one base standard is a Good Thing. A note for folks working with dates where YYYY < 0000 or YYYY > 9999: I know ISO 8601 isn't right for you. You'll need to use another standard which fits your requirement. Sorry. ISO 8610 is a *very* permissive standard and so each Internet-related protocol/standard is making up its own profile of ISO 8601. That is a Bad Thing. Some of these are conformant profiles; others are not. And that's a Very Bad Thing. Some of the profiles are more restrictive; others are less so. An example of a non-conformant profile is that used by PICS 1.1 [REC-PICS-labels-961031]; see the extract below. This profile is non-conformant in that it separates the YYYY and MM and DD portions using the character "." instead of "-". The PICS profile is also surprisingly restrictive, in that it does not permit seconds to be included. An example of a conformant profile is that used by [draft-newman-datetime-01.txt]. This profile is also rather restrictive for some Internet-related protocols and standards, in that it mandates the use of hours, minutes and seconds. Some users may wish to specify only a date when creating metadata. Chris has agreed to make the time portion optional in his next draft. I would suggest we need a single profile which is: - conformant, - widely adopted, - easy to understand, - not too permissive, - not too restrictive, - electronically available. We also need to persuade the people specifying forthcoming standards such as PICS-NG, Cougar, etc, to use this profile. So, how do we proceed? Chris Newman's Internet Draft has two further disadvantages: (i) it's an Internet Draft (rather than an RFC) and (ii) it is made rather large and intimidating by catering for dates/times in the future and the associated mish-mash (did I spell that right?) of time zones. One possibility would be for Chris, who is currently busy on other important stuff, to find the time to split his Internet Draft into two: (i) a quickie covering just a profile of ISO 8601 and (ii) another, covering the more complex stuff. Another possibility would be for someone else to do the job (I'm not volunteering). Comments? A note on distribution: I have not found a single suitable forum for this topic, so I suggest it be discussed on the open lists (meta2(a)mrrl.lut.ac.uk) and (www-html(a)w3.org) and request that you send your responses to those two lists. I'll forward this initial message to a few other relevant lists, mostly closed ones, to give people on those lists notice of this thread. REFERENCES: [ISO 8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988. [REC-PICS-labels-961031] "PICS Label Distribution Label Syntax and Communication Protocols", Version 1.1, W3C Recommendation 31-October-96. [draft-newman-datetime-01.txt] "Date and Time on the Internet", Chris Newman, Internet Draft, January 1997. An extract from [REC-PICS-labels-961031] follows: quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"' based on the ISO 8601:1988 date and time standard, restricted to the specific form described here: YYYY :: four-digit year MM :: two-digit month (01=January, etc.) DD :: two-digit day of month (01 through 31) hh :: two digits of hour (00 through 23) (am/pm NOT allowed) mm :: two digits of minute (00 through 60) S :: sign of time zone offset from UTC ('+' or '-') tz :: four digit amount of offset from UTC (e.g., 1512 means 15 hours and 12 minutes) For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date denoting November 5, 1994, 8:15 am, US Eastern Standard Time Note: The ISO standard allows considerably greater flexibility than that described here. PICS requires precisely the syntax described here -- neither the time nor the time zone may be omitted, none of the alternate formats are permitted, and the punctuation must be as specified here. ----------------------------------------------------------------------- Misha Wolf Email: misha.wolf(a)reuters.com 85 Fleet Street Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ Reuters Limited Fax : +44 171 542 8314 UK ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

help
by Michael.Matschir＠zamg.ac.at June 11, 1997

June 11, 1997

1 0

Small patches for tzcode1997e.tar.gz
by Andreas Jaeger June 4, 1997

June 4, 1997

Hi, I've send the following mail already once to the list but neither get an reply nor find it in tzarchive. Let's give it another try. I've noticed that tzcode1997e has some prototype definitions that don't match the actual function headers. I've appended a patch for private.h and also for scheck.c (I think that both parameters should be the same) and hope you can use it. Thanks for a really good package. Cheers, Andreas diff -cr tzcode1997e/private.h tz/private.h *** tzcode1997e/private.h Sun May 4 00:52:23 1997 --- tz/private.h Wed May 21 16:56:12 1997 *************** *** 176,188 **** ** Private function declarations. */ char * icalloc P((int nelem, int elsize)); ! char * icatalloc P((char * old, const char * new)); ! char * icpyalloc P((const char * string)); ! char * imalloc P((int n)); ! void * irealloc P((void * pointer, int size)); ! void icfree P((char * pointer)); ! void ifree P((char * pointer)); ! char * scheck P((const char *string, char *format)); /* --- 176,188 ---- ** Private function declarations. */ char * icalloc P((int nelem, int elsize)); ! char * icatalloc P((char * const old, const char * const new)); ! char * icpyalloc P((const char * const string)); ! char * imalloc P((const int n)); ! void * irealloc P((void * const pointer, const int size)); ! void icfree P((char * const pointer)); ! void ifree P((char * const pointer)); ! char * scheck P((const char * const string, const char * const format)); /* diff -cr tzcode1997e/scheck.c tz/scheck.c *** tzcode1997e/scheck.c Sun May 4 00:52:25 1997 --- tz/scheck.c Wed May 21 16:52:54 1997 *************** *** 11,17 **** char * scheck(string, format) const char * const string; ! char * const format; { register char * fbuf; register const char * fp; --- 11,17 ---- char * scheck(string, format) const char * const string; ! const char * const format; { register char * fbuf; register const char * fp; -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)alma.student.uni-kl.de http://www.student.uni-kl.de/~ajaeger/

1 0

spamming
by Sue Ann Bowling June 2, 1997

June 2, 1997

Is it possible to set up a filter such that only messages from outsiders and new list members (say for less than a month) be monitored? Sue Ann Bowling, Geophysical Institute, University of Alaska Fairbanks Professional URL http://climate.gi.alaska.edu/Bowling/Bowling.html Dog URL http://www.mcf.com/bowlingsite/dogpage.html

1 0

spam
by ado May 27, 1997

May 27, 1997

Right now the time zone list is handled on a UNIX system; mail sent to "tz" gets forwarded (as a result of an "/etc/aliases" entry) to the addresses that appear in a file maintained by hand. If anyone can recommend a filtering program to use in the /etc/aliases entry, I'd appreciate hearing from you by electronic mail to arthur_david_olson(a)nih.gov --ado

1 0

Re: Re: Answers to questions, spam problems
by Dave Skinner May 27, 1997

May 27, 1997

> > Dave Skinner writes: > > > I agree that the spammers should be stopped, and if that takes > > > monitoring postings before they are actually posted, then so be it. > > > Chris Carrier writes: > > The only posts that would be monitored/moderated would be those from > > non-tz subscribers; not an undue burden. > Dik Winters writes: > I do not believe that. Currently spammers are using throw-away accounts, > shortly they will be using throw-away subscribtions. Not to dwell on this subject for too long, but I tend to agree with Chris Carrier on this one, and I'm the one at the top of this sequence of quotes. I grew up where burglaries were rare, but did occur. So, we locked our doors when we left the house. By comparison, we had friends in rural Ohio who never locked their doors when they left the house; there was no need. Now, I live in one of the maze of cities and towns that make up the greater Los Angeles area, and there are many areas, that fortunately do not include the one in which I live, but which are nearby, that not only feel they need to lock their doors, but also the need to put bars on their own windows, which can really get in the way of the fire department should there be a fire. The point of this analogy is that letting subscriber articles through unmonitored is working for now as witnessed by Chris Carrier writes: > So the list moderator decided to require that all posts sent from non- > subscribers be cleared through him. Posts from subscribers are still > automatically posted. No spam has appeared on the list since this > policy was adopted five months ago. I would say we have been, up till now, operating like my friends in Ohio. At the point where we feel the spam has gotton bad enough, and I am not sure we are at that point yet, but if and when we get to that point, then we should do the equivalent of locking our doors, i.e. we probably should have non-subscriber articles be monitored. If that gets the job done, then we should leave our anti-spam security measures at that level. At a later time if the spammers start using "throw-away subscriptions" as Dik Winters fears, and if the spam again becomes a significant problem, then we should regretfully do the equivalent of adding the bars to our own windows as well. We can always take this more draconian precaution, but I really hate giving up freedoms, and adding work to the maintainers of this list, unless it really becomes necessary. We should not make the cure worse than the disease. Although I am switching analogies as I state the following, I really do not think we should have representatives of the post office, so to speak, censoring our mail simply to avoid that portion which is junk mail. Dave Skinner

1 0

Re: Answers to questions, spam problems
by Dik.Winter＠cwi.nl May 25, 1997

May 25, 1997

> >I totally agree that the spammers should be stopped, and if that takes > >monitoring postings before they are actually posted, then so be it. > > The only posts that would be monitored/moderated would be those from non-tz > subscribers; not an undue burden. I do not believe that. Currently spammers are using throw-away accounts, shortly they will be using throw-away subscribtions. dik

1 0

Answers to questions, spam problems
by Chris Carrier May 24, 1997

May 24, 1997

Joe Celko [71062.1056(a)compuserve.com] quotes me: >>... the growth of standard time laws. Don't remember much more about it, >>but the full story is in "The History of American Time." >Would you mind giving me the full reference for that book? Unfortunately I don't have a full reference. I remember it came out about 1990, and forget the author's name. It deals mostly with the establishment of standard time, with the last chapter devoted to daylight time. sharris(a)apple.com also quotes me: >Another, related mailing list I subscribe to, CALNDR-L, >run by Rick McCarty of East Carolina University, was suffering from spam >Can you tell me a bit about this list you are referring to, and how one can >subscribe? The list is about calendars: actual and proposed, along with related subjects, like the number of days in a year and the change in that number (which of course is related to leap seconds). It's been up since last October. To subscribe, send a one-line email SUBSCRIBE CALNDR-L to LISTSERV(a)ECUVM.CIS.ECU.EDU. In December members of CALNDR-L started to receive spam from various sources. So the list moderator decided to require that all posts sent from non- subscribers be cleared through him. Posts from subscribers are still automatically posted. No spam has appeared on the list since this policy was adopted five months ago. Although it is possible that a subscriber could send spam, anyone who did would be expelled from the list and everyone on the list is a sensible person who would not do such a thing. I would advocate a similar policy here on tz to stop spam. Dave Skinner (dave(a)kirdu.jpl.nasa.gov) wrote: >I totally agree that the spammers should be stopped, and if that takes >monitoring postings before they are actually posted, then so be it. The only posts that would be monitored/moderated would be those from non-tz subscribers; not an undue burden. Chris

1 0