- tz - lists.iana.org

Re: Proposed change for new U. S. law; also, what about Indiana?
by Paul Eggert Aug. 17, 2005

Aug. 17, 2005

> Date: Fri, 12 Aug 2005 22:25:41 -0400 > From: John Hawkinson <jhawk(a)MIT.EDU> > > [ I had originally sent a version of this on Tuesday morning, but it > failed to go through because apparently lecserver.nci.nih.gov is still > firewalled, and elsie works only because of an MX record. ] Yes, things are still much messed up for me as well. I am getting no copies of email (I had to FTP the mail archive from elsie to see your mail). Also, the email headers get rewritten to be from tz(a)lecserver.nci.nih.gov, so when people reply to email their messages do not get through. Perhaps we should move the list elsewhere? I can volunteer the GNU email server <http://lists.gnu.org/>, if that would help. > HR numbers are per-year (e.g. HR.6 of the 109th Congress), and are > really only useful before bills become laws. I expect it will be > assigned a Public Law number sometime this coming week, and that will > appear at "http://thomas.loc.gov/cgi-bin/bdquery/z?d109:HR00006:@@@S". > > Can we wait until then and include that number? I wouldn't wait. We can update the comment later. > p.s.: I keep wondering if its a good time to propose changing the > default name of US timezones to US/Eastern -style rather than > America/New_York, because our timezones are set based on national > policy Unfortunately that's not quite true. The daylight-saving rules are national policy, but whether to adopt daylight-saving is decided more locally. (Speaking of which, what is the story on Indiana? <http://www.perrycountynews.com/articles/2005/08/15/top_story/t1.txt> says that Indiana will observe DST starting next year. Is that really true?) Also, time zone boundaries move. So, for example, US/Eastern is not correct for Monticello, KY, as it will mishandle time stamps before 2000 (Monticello switched from Central to Eastern in fall 2000). We will continue to support names like US/Eastern indefinitely, but the location-based names are more accurate.

3 4

Re: Web page updates
by Paul Eggert Aug. 16, 2005

Aug. 16, 2005

Thanks for the link updates. I'll let Arthur handle the tz-art.htm change. For tz-link.htm you write: > The link http://www.astrologyhouse.co.nz/timechanges.htm does not exist > anymore, and I can not find a relocated page at the web site. Please see <http://www.astrologyschool.com/nztime.html>. > The link http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2 does not > exist anymore, and I can not find a relocated page at the web site. Please see <http://www.bom.gov.au/climate/averages/tables/dst_times.shtml>. > The link http://www.nationalatlas.gov/timeznm.html does not exist > anymore. http://nationalatlas.gov/mld/timeznp.html seems to be a > suitable replacement. Yes, thanks, I found that one just a few hours ago myself. I'll propose a patch for these (and other) problems soon.

1 0

Re: Multi-timezone clock
by Paul Eggert Aug. 16, 2005

Aug. 16, 2005

peter.verthez(a)alcatel.be writes: > http://freshmeat.net/projects/intclock Thanks for letting us know about that; I'll add a reference in my next proposed tz patch. I use Debian, so I hope intclock gets added as a Debian package some day.

1 0

Re: Request from CLDR committee
by Paul Eggert Aug. 16, 2005

Aug. 16, 2005

> From: "Mark Davis" <mark.davis(a)icu-project.org> > Sent: Tuesday, August 09, 2005 07:28 > > 1. Missing Country Codes. > ... > Suggested changes: > To antarctica, add > Zone Atlantic/Bouvet 0:00 - GMT > Zone Pacific/Heard 5:00 - GMT The problem with this approach, as I see it, is that the data are purely invented. Heard Island is not 5 hours ahead of GMT, since nobody lives there. In a practical sense, local time is undefined for uninhabited locations, and it would be misleading for the tz database to imply otherwise. I suppose we could work around this by using a "zzz" entry, e.g.: Zone Indian/Heard 0:00 - zzz but I wonder whether this might cause more troubles than it'd cure. "zzz" currently is used to denote local time for locations that are sometimes inhabited and sometimes uninhabited. However, this is a hack: what is really wanted is a relation where the entries for local time are simply absent while the location is uninhabited. As far as I can tell, the country codes HM and BV are ISO 3166 curiosities. For example, www.bv is now owned by Black & Veatch, a privately-held firm that two of my cousins work for -- it has nothing to do with Bouvet Island. I wouldn't worry too much about these glitches in the ISO database. > 2. Enabling Canonical IDs > > One dependency we have is that the last field in the canonical ID be unique. > That is, we can't have both a Europe/London and an America/London. I wouldn't rely on this. It's too constraining on the database. Part of the point of having a tree-structured name space is the desire to avoid constraints like these. > This appears to be the practice in > the TZ database, as evidenced by the following in southamerica: > > # Bahia (BA) > # There are too many Salvadors elsewhere, so use America/Bahia instead > # of America/Salvador. That comment refers to the other Salvadors in America. If there were a Salvador in Africa (or even in America/Argentina) it wouldn't be a problem. > We also depend on the feature that every equivalence class (except Etc/...) > has exactly one member in zone.tab. That sounds reasonable. How about if we add something to Theory saying that zone.tab "is intended to be an exhaustive list of canonical names for geographic regions." > List A. TZIDs that are not linked, but are the same > > 001 Etc/GMT > 001 Etc/UTC > 001 Etc/UCT -- not linked, identical They are not identical, since they use different abbreviations. Hence they cannot be linked. For example, on my Debian GNU/Linux 3.1 box: $ TZ=Etc/GMT date Tue Aug 16 17:31:23 GMT 2005 $ TZ=Etc/UTC date Tue Aug 16 17:31:27 UTC 2005 The difference in output is intentional. How about if you simplify your life by simply ignoring the Etc/* names? > List B. TZIDs that are not linked, are different locations, but are the same > since 1970 > > AQ Antarctica/Mawson > AQ Antarctica/Vostok -- same since 57 As far as I know it's merely a coincidence that the two bases use the same time zone. Most crucially the bases belong to different countries (so to some extent the "different country" rule applies, though admittedly Antarctica is special) and use different supply lines. I'd rather leave them alone for now. > FM Pacific/Truk > FM Pacific/Yap -- same since 70 > GB Europe/Belfast > GB Europe/London -- same since 68 > ML Africa/Bamako > ML Africa/Timbuktu -- same since 60 OK, let's merge those. It is more consistent to do so. We'll keep backward-compatibility entries, of course. Sigh. I sort of liked having Timbuktu in the database. > List C. TZIDs that are linked, but refer to different locations. As a rule, these locations have identical time zone histories except before the advent of standard time; and LMT (by definition) is approximate, so I don't see the harm in keeping them linked. If they are trouble for your system, perhaps you can keep a list of exceptions and filter them out. That being said, perhaps some of the "Link" lines should be moved from northamerica (etc.) to backward. For example, the line Link America/New_York EST5EDT is in the "northamerica" file, but it's really there only for backward compatibility with System V, so perhaps we should move it to "backward". Arthur, would you be open to that sort of thing?

1 0

Re: DST rules for Poland: corrections for 1946-1949 and 1988-1998
by Paul Eggert Aug. 16, 2005

Aug. 16, 2005

Przemyslaw Augustyniak <silvathraec(a)rpg.pl> writes: > Tzdata 2005i has two minor inaccuracies in historical DST rules for > Poland: > > * 1946-1949 DST transition dates are partially incorrect, see patch > below. > > * Poland reintroduced DST in 1977, together with European Economic > Community, but with DST transitions 1h behind EC ones. This difference > is incorrectly listed as being dropped only as late as in 1999, rather > than in 1988. Thanks very much for tracking this information down and listing your sources. I'll include this info in my next proposed patch to the tz data. > Sources: > > * Kazimierz M. Borkowski, "Wszystko o czasie" > <http://www.astro.uni.torun.pl/~kb/Artykuly/U-PA/Czas2.htm#tth_tAb1> > > * Druk nr 2180 - o czasie urzędowym na obszarze Rzeczypospolitej Polskiej > <http://www.senat.gov.pl/k5/dok/sejm/053/2180.pdf> > > * Uchwała nr 29 Rady Ministrów z dnia 7 marca 1995 r. w sprawie > wprowadzenia czasu letniego i zimowego w 1995 r. > [M.P. 1995 nr 13 poz. 162] > <http://www.abc.com.pl/serwis/mp/1995/0162.htm> > > > You are welcome to contact me if you have any questions. I'm not on the > list, so please CC me when replying. > > Przemysław Augustyniak > > > --- europe.2005i 2005-04-21 21:04:15.000000000 +0200 > +++ europe 2005-05-28 13:32:51.555884081 +0200 > @@ -1686,19 +1686,23 @@ > # For 1944-1948 Whitman gives the previous day; go with Shanks. > Rule Poland 1945 only - Apr 29 0:00 1:00 S > Rule Poland 1945 only - Nov 1 0:00 0 - > -Rule Poland 1946 only - Apr 14 0:00 1:00 S > -Rule Poland 1946 only - Sep 7 0:00 0 - > -Rule Poland 1947 only - May 4 0:00 1:00 S > -Rule Poland 1947 1948 - Oct Sun>=1 0:00 0 - > -Rule Poland 1948 only - Apr 18 0:00 1:00 S > -# Whitman also gives 1949 Apr 9 - 1949 Oct 1; go with Shanks. > +# dr Kazimierz M. Borkowski > +# Torun Centre for Astronomy of Nicolaus Copernicus University > +# Department of Radio Astronomy > +# <http://www.astro.uni.torun.pl/~kb/Artykuly/U-PA/Czas2.htm#tth_tAb1> > +Rule Poland 1946 only - Apr 14 0:00s 1:00 S > +Rule Poland 1946 only - Oct 7 2:00s 0 - > +Rule Poland 1947 only - May 4 2:00s 1:00 S > +Rule Poland 1947 1949 - Oct Sun>=1 2:00s 0 - > +Rule Poland 1948 only - Apr 18 2:00s 1:00 S > +Rule Poland 1949 only - Apr 10 2:00s 1:00 S > Rule Poland 1957 only - Jun 2 1:00s 1:00 S > Rule Poland 1957 1958 - Sep lastSun 1:00s 0 - > Rule Poland 1958 only - Mar 30 1:00s 1:00 S > Rule Poland 1959 only - May 31 1:00s 1:00 S > Rule Poland 1959 1961 - Oct Sun>=1 1:00s 0 - > Rule Poland 1960 only - Apr 3 1:00s 1:00 S > -Rule Poland 1961 1964 - May Sun>=25 1:00s 1:00 S > +Rule Poland 1961 1964 - May lastSun 1:00s 1:00 S > Rule Poland 1962 1964 - Sep lastSun 1:00s 0 - > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Europe/Warsaw 1:24:00 - LMT 1880 > @@ -1707,24 +1711,8 @@ > 2:00 Poland EE%sT 1922 Jun > 1:00 Poland CE%sT 1940 Jun 23 2:00 > 1:00 C-Eur CE%sT 1944 Oct > - 1:00 Poland CE%sT 1977 Apr 3 1:00 > - 1:00 W-Eur CE%sT 1999 > -# IATA SSIM (1991/1996) gives EU rules, but the _The Warsaw Voice_ > -# <a href="http://www.warsawvoice.com.pl/v361/NewsInBrief.shtml"> > -# http://www.warsawvoice.com/pl/v361/NewsInBrief.shtml (1995-09-24) > -# </a> > -# says the autumn 1995 switch was at 02:00. > -# Stick with W-Eur for now. > -# > -# From Marcin.Kasperski(a)softax.com.pl (1999-06-10): > -# According to my colleagues someone recently decided, that Poland would > -# follow European Union regulations, so - I think - the matter is not > -# worth further discussion. > -# > -# From Paul Eggert (1999-06-10): > -# Kasperski also writes that the government futzed with the rules in 1997 > -# or 1998 but he doesn't remember the details. Assume they switched to > -# EU rules in 1999. > + 1:00 Poland CE%sT 1977 > + 1:00 W-Eur CE%sT 1988 > 1:00 EU CE%sT > # Portugal

1 0

Kyrgyzstan abolishes daylight saving time; tz mailing list problems?
by Paul Eggert Aug. 15, 2005

Aug. 15, 2005

According to an article dated today in the Kyrgyzstan Development Gateway <http://eng.gateway.kg/cgi-bin/page.pl?id=1&story_name=doc9979.shtml> Kyrgyzstan is canceling the daylight saving time system. The text of the article is somewhat ambiguous: According to the adopted resolution, the practice of daylight saving time is cancelled. Time calculation on the territory of the Kyrgyz Republic will be carried out in compliance with the international time zone system, with 1-hour advance, what corresponds to the time calculation order, which is active from March 27, 2005. but I take this to mean that they will leave their clocks at 6 hours ahead of UTC, and will not fall back this autumn. PS. I just got back from vacation (with one of the first things to do to propose a new tz patch for all the accumulated data) and discovered that I am not receiving email from the tz mailing list. I haven't gotten anything for several weeks. I'll try to retrieve old mail from tzarchive (currently dated August 9 19:20), but has something happened to the mailing list recently?

1 0

Proposed change for new U. S. law
by Arthur David Olson Aug. 13, 2005

Aug. 13, 2005

Below find my proposed change to the "northamerica" file to reflect new U. S. law. --ado ------- northamerica ------- *** /tmp/geta1562 Tue Aug 9 09:29:26 2005 --- /tmp/getb1562 Tue Aug 9 09:29:26 2005 *************** *** 1,4 **** ! # @(#)northamerica 7.75 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, --- 1,4 ---- ! # @(#)northamerica 7.76 # also includes Central America and the Caribbean # This data is by no means authoritative; if you think you know better, *************** *** 116,130 **** Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep 30 2:00 0 S ! Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D ! Rule US 1987 max - Apr Sun>=1 2:00 1:00 D ! # <a href="http://thomas.loc.gov/cgi-bin/bdquery/z?d106:h.r.00177:"> ! # H.R.177 ! # </a> (introduced 1999-01-06) would change April to March in the above rule. # From Bob Devine (1988-01-28): # ...Alaska (and Hawaii) had the timezone names changed in 1967. --- 116,129 ---- Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep 30 2:00 0 S ! Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D ! Rule US 1987 2006 - Apr Sun>=1 2:00 1:00 D ! Rule US 2007 max - Mar Sun>=8 2:00 1:00 D ! Rule US 2007 max - Nov Sun>=1 2:00 0 S # From Bob Devine (1988-01-28): # ...Alaska (and Hawaii) had the timezone names changed in 1967. *************** *** 202,209 **** # Public law 106-564 (2000-12-23) introduced the abbreviation # "Chamorro Standard Time" for time in Guam and the Northern Marianas. # See the file "australasia". - # US eastern time, represented by New York # Connecticut, Delaware, District of Columbia, most of Florida, --- 201,227 ---- # Public law 106-564 (2000-12-23) introduced the abbreviation # "Chamorro Standard Time" for time in Guam and the Northern Marianas. # See the file "australasia". + + # From Arthur David Olson, 2005-08-09 + # The following was signed into law on 2005-08-08. + # + # H.R. 6, Energy Policy Act of 2005, SEC. 110. DAYLIGHT SAVINGS. + # (a) Amendment- Section 3(a) of the Uniform Time Act of 1966 (15 + # U.S.C. 260a(a)) is amended-- + # (1) by striking `first Sunday of April' and inserting `second + # Sunday of March'; and + # (2) by striking `last Sunday of October' and inserting `first + # Sunday of November'. + # (b) Effective Date- Subsection (a) shall take effect 1 year after the + # date of enactment of this Act or March 1, 2007, whichever is later. + # (c) Report to Congress- Not later than 9 months after the effective + # date stated in subsection (b), the Secretary shall report to Congress + # on the impact of this section on energy consumption in the United + # States. + # (d) Right to Revert- Congress retains the right to revert the + # Daylight Saving Time back to the 2005 time schedules once the + # Department study is complete. # US eastern time, represented by New York # Connecticut, Delaware, District of Columbia, most of Florida,

2 1

FW: Web page updates
by Olson, Arthur David (NIH/NCI) Aug. 11, 2005

Aug. 11, 2005

Frank Vance is not on the time zone mailing list (at least not at the address below); direct replies appropriately. --ado -----Original Message----- From: Frank Vance [mailto:frankvance@mindspring.com] Sent: Wednesday, August 10, 2005 11:45 AM To: tz(a)lecserver.nci.nih.gov Subject: Web page updates tz-art.html: The link http://www.videoflicks.com/VF2/1035/1035893.ihtml should be changed to: http://www.videoflicks.com/titles/1035/1035893.htm tz-links.htm: The link http://www.astrologyhouse.co.nz/timechanges.htm does not exist anymore, and I can not find a relocated page at the web site. The link http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2 does not exist anymore, and I can not find a relocated page at the web site. The link http://www.nationalatlas.gov/timeznm.html does not exist anymore. http://nationalatlas.gov/mld/timeznp.html seems to be a suitable replacement.

1 0

Web page updates
by Frank Vance Aug. 10, 2005

Aug. 10, 2005

tz-art.html: The link http://www.videoflicks.com/VF2/1035/1035893.ihtml should be changed to: http://www.videoflicks.com/titles/1035/1035893.htm tz-links.htm: The link http://www.astrologyhouse.co.nz/timechanges.htm does not exist anymore, and I can not find a relocated page at the web site. The link http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2 does not exist anymore, and I can not find a relocated page at the web site. The link http://www.nationalatlas.gov/timeznm.html does not exist anymore. http://nationalatlas.gov/mld/timeznp.html seems to be a suitable replacement.

1 0

FW: Request from CLDR committee
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

Mark Davis is not on the time zone mailing list (at least not at the address below); direct replies appropriately. --ado ----- Original Message ----- From: "Mark Davis" <mark.davis(a)icu-project.org> To: "Tz (tz(a)elsie.nci.nih.gov)" <tz(a)lecserver.nci.nih.gov> Cc: "Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> Sent: Tuesday, August 09, 2005 07:28 Subject: Request from CLDR committee The CLDR technical committee has been looking at issues that have come up in connection with timezones, and have the following requests of the TZ group. Background. As discussed previously on this list, the CLDR project supplies localizations for timezone identifiers, based on the TZ IDs from the TZ database. The localizations can either be explicit strings, or if unavailable, use the translated country name (where a country has only a single timezone) or fall back to the last field of the TZID and the translated country name. Thus in German: America/Havana => "Kuba" Europe/Moscow => "Moskau (Russische Föderation)" America/Los_Angeles => "Los Angeles (Vereinigte Staaten)" The process is somewhat more complicated than this description, but this provides the gist. For other examples, see http://unicode.org/cldr/data/common/test/ with different locales. (BTW, a corrigendum was issued for the GMT problem raised earlier; see http://unicode.org/cldr/corrigenda.html) Requests. 1. Missing Country Codes. There are two missing ISO country codes. While these are uninhabited rocks, they should be added according to Theory, which says: " Include at least one location per time zone rule set per country. One such location is enough. Use ISO 3166 (see the file iso3166.tab) to help decide whether something is a country. " There are also good, practical reasons to do this; an implementation that maps from country codes to sets of zones needs to have some value for all ISO country codes. The two ISO codes are: HM 53 06 S, 72 31 E Heard Island and McDonald Islands BV 54 26 S, 3 24 E Bouvet Island (locations are from http://www.cia.gov/cia/publications/factbook/geos/bv.html http://www.cia.gov/cia/publications/factbook/geos/hm.html ) Suggested changes: To zone.tab, add HM -5306+7231 Pacific/Heard BV -5426+0324 Atlantic/Bouvet To antarctica, add Zone Atlantic/Bouvet 0:00 - GMT Zone Pacific/Heard 5:00 - GMT 2. Enabling Canonical IDs The Link commands in the database establish equivalence classes between TZIDs (aka "location names"). For an implementation like CLDR, it is important that there be a completely stable canonical TZID that represents any of those equivalents. Based on feedback from this list, we chose it to be: a) the TZID in zone.tab as of 2004a, or b) any new TZID in a later version of zone.tab that is not equivalent to a TZID introduced in an earlier version. That is, we use America/Buenos_Aires since it was in 2004a, and America/Argentina/Tucuman since it was introduced later. One dependency we have is that the last field in the canonical ID be unique. That is, we can't have both a Europe/London and an America/London. Now, if the TZ database ever added a TZID that was not unique in this sense, we could add our own canonical ID outside of the TZ database, but that is clearly not our preference, not at all. This appears to be the practice in the TZ database, as evidenced by the following in southamerica: # Bahia (BA) # There are too many Salvadors elsewhere, so use America/Bahia instead # of America/Salvador. We also depend on the feature that every equivalence class (except Etc/...) has exactly one member in zone.tab. To avoid having to hack around problems in the future, we would like this to be captured in Theory as requirements for the construction of future IDs. This is in no way a functional restriction, just on the choice of names. Thus, we propose the addition of something like the following to the "rules used for choosing location names" in Theory. All locations (the final field in a location name) must be unique. Thus one cannot have Europe/London and either America/London or America/Canada/London. Two location names that appear in zone.tab cannot be Linked together, either directly or through a chain of Links. Conversely, every location (except for those starting with "Etc") must be Linked to a location name in zone.tab. 3. Definitional Links. For the purpose of something like CLDR, it is important to separate out the *definitional* equivalents from the *incidental* equivalents (equivalencies that happen to be true for now, but could change in the future). You don't want to include two TZIDs in the same definitional equivalence class if they are ever different, or could be in the future, because then comparisons between TZIDs (as equivalent) could be true now, but fail in the future. After looking at the equivalence classes established by Link, it turns out that there are a few anomalies. Now, Theory says: " If all the clocks in a country's region have agreed since 1970, don't bother to include more than one location even if subregions' clocks disagreed before 1970. Otherwise these tables would become annoyingly large. " This makes a great deal of sense. After all, if we go back to when daylight savings started, then every location on earth (that didn't share a longitude with another location) would be a separate TZID. However, there are a small number of anomalous cases. List A below contains items that should be Linked, since they are always and will always be equivalent (as far as TZ calculations go). List B contains cases that have been the same since 1970, but are not Linked. So they appear to violate the condition above in Theory. Conversely, List C contains cases that clearly reference different locations, and thus before timezones were added, they had different offsets (sun time). So if the same criteria are applied as in List B, they would be unlinked. So we request that the items in List A be linked, and each of the pairs in List B and C be treated consistently: Option 1. Leave (or make) the pair Linked, and pick one item in each pair, and document that it is obsolete, and will never be unlinked from the other. Option 2. Leave (or make) the pair Unlinked. If it was previously Linked, then thus according to #2 above, one of the pair would be added to zone.tab. And add to Theory, under "rules used for choosing location names". As of version X, whenever two location names have been linked in the past, for stability they will remain linked forever. ============= List A. TZIDs that are not linked, but are the same 001 Etc/GMT 001 Etc/UTC 001 Etc/UCT -- not linked, identical List B. TZIDs that are not linked, are different locations, but are the same since 1970 AQ Antarctica/Mawson AQ Antarctica/Vostok -- same since 57 FM Pacific/Truk FM Pacific/Yap -- same since 70 GB Europe/Belfast GB Europe/London -- same since 68 ML Africa/Bamako ML Africa/Timbuktu -- same since 60 List C. TZIDs that are linked, but refer to different locations. (This was derived by inspection; if there are other cases of IDs that refer to different locations, please let us know.) AQ Antarctica/McMurdo AQ Antarctica/South_Pole -- linked, different places SJ Arctic/Longyearbyen SJ Atlantic/Jan_Mayen -- linked, different places US America/Denver US America/Shiprock -- linked, different places AR America/Argentina/Cordoba AR America/Rosario -- linked, different places AU Australia/Sydney AU Australia/Canberra -- linked, different places BR America/Rio_Branco BR America/Porto_Acre -- linked, different places BR Brazil/Acre ? IL Asia/Jerusalem IL Asia/Tel_Aviv -- linked, different places MD Europe/Chisinau MD Europe/Tiraspol -- linked, different places MX America/Tijuana MX America/Ensenada -- linked, different places US America/Indianapolis US America/Fort_Wayne -- linked, different places

1 0

RE: bug introduced in tzcode2005c
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

The infinite loop is caused by my failure to check for overflow; here's a proposed fix. --ado ------- localtime.c ------- *** /tmp/geta2299 Tue Aug 9 09:56:30 2005 --- /tmp/getb2299 Tue Aug 9 09:56:30 2005 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.95"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.96"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1616,1624 **** --- 1616,1628 ---- if (dir != 0) { if (t == lo) { ++t; + if (t <= lo) + return WRONG; ++lo; } else if (t == hi) { --t; + if (t >= hi) + return WRONG; --hi; } if (lo > hi)

1 0

FW: bug introduced in tzcode2005c
by Olson, Arthur David (NIH/NCI) Aug. 9, 2005

Aug. 9, 2005

Todd C. Miller is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Todd C. Miller [mailto:Todd.Miller@courtesan.com] Sent: Monday, August 08, 2005 11:29 PM To: tz(a)lecserver.nci.nih.gov Subject: bug introduced in tzcode2005c A change in tzcode 2005c causes the following program on OpenBSD to loop forever. I've tracked it down to the change included at the end of this message. Previously:: $ ./mktime Timestamp is: -1 Date is: Thu Jan 1 00:59:59 1970 With tzcode 2005c and beyond it loops forever. #include <sys/types.h> #include <stdio.h> #include <time.h> #include <stdlib.h> /* * This small programm will consume 100% CPU and loops forever with * tzcode 2005c - 2005k. */ int main(int argc, char **argv) { time_t timet; struct tm tm; tm.tm_sec = 36; tm.tm_min = 5; tm.tm_hour = 23; tm.tm_mday = 31; tm.tm_mon = 11; tm.tm_year = 138; /* 2038 - 1900 */ tm.tm_isdst = 0; timet = mktime(&tm); printf("Timestamp is: %d\n", timet); printf("Date is: %s\n", ctime(&timet)); exit(0); } Here's the change that triggers it. --- tzcode2005b/localtime.c Mon Jan 10 07:19:41 2005 +++ tzcode2005c/localtime.c Mon Jan 17 16:36:15 2005 @@ -1441,10 +1436,11 @@ { register const struct state * sp; register int dir; - register int bits; register int i, j; register int saved_seconds; register long li; + register time_t lo; + register time_t hi; long y; time_t newt; time_t t; @@ -1518,28 +1514,49 @@ yourtm.tm_sec = 0; } /* - ** Divide the search space in half - ** (this works whether time_t is signed or unsigned). + ** Do a binary search (this works whatever time_t's type is). */ - bits = TYPE_BIT(time_t) - 1; - /* - ** If time_t is signed, then 0 is just above the median, - ** assuming two's complement arithmetic. - ** If time_t is unsigned, then (1 << bits) is just above the median. - */ - t = TYPE_SIGNED(time_t) ? 0 : (((unsigned long) 1) << bits); + if (!TYPE_SIGNED(time_t)) { + lo = 0; + hi = lo - 1; + } else if (!TYPE_INTEGRAL(time_t)) { + if (sizeof(time_t) > sizeof(float)) + hi = (time_t) DBL_MAX; + else hi = (time_t) FLT_MAX; + lo = -hi; + } else { + lo = 1; + for (i = 0; i < (int) TYPE_BIT(time_t) - 1; ++i) + lo *= 2; + hi = -(lo + 1); + } for ( ; ; ) { - if ((*funcp)(&t, offset, &mytm) == NULL) - return WRONG; /* XXX probably wrong */ - dir = tmcomp(&mytm, &yourtm); + t = lo / 2 + hi / 2; + if (t < lo) + t = lo; + else if (t > hi) + t = hi; + if ((*funcp)(&t, offset, &mytm) == NULL) { + /* + ** Assume that t is too extreme to be represented in + ** a struct tm; arrange things so that it is less + ** extreme on the next pass. + */ + dir = (t > 0) ? 1 : -1; + } else dir = tmcomp(&mytm, &yourtm); if (dir != 0) { - if (bits-- < 0) + if (t == lo) { + ++t; + ++lo; + } else if (t == hi) { + --t; + --hi; + } + if (lo > hi) return WRONG; - if (bits < 0) - --t; /* may be needed if new t is minimal */ - else if (dir > 0) - t -= ((long) 1) << bits; - else t += ((long) 1) << bits; + if (dir > 0) + hi = t; + else lo = t; continue; } if (yourtm.tm_isdst < 0 || mytm.tm_isdst == yourtm.tm_isdst)

1 0

bug introduced in tzcode2005c
by Todd C. Miller Aug. 9, 2005

Aug. 9, 2005

A change in tzcode 2005c causes the following program on OpenBSD to loop forever. I've tracked it down to the change included at the end of this message. Previously:: $ ./mktime Timestamp is: -1 Date is: Thu Jan 1 00:59:59 1970 With tzcode 2005c and beyond it loops forever. #include <sys/types.h> #include <stdio.h> #include <time.h> #include <stdlib.h> /* * This small programm will consume 100% CPU and loops forever with * tzcode 2005c - 2005k. */ int main(int argc, char **argv) { time_t timet; struct tm tm; tm.tm_sec = 36; tm.tm_min = 5; tm.tm_hour = 23; tm.tm_mday = 31; tm.tm_mon = 11; tm.tm_year = 138; /* 2038 - 1900 */ tm.tm_isdst = 0; timet = mktime(&tm); printf("Timestamp is: %d\n", timet); printf("Date is: %s\n", ctime(&timet)); exit(0); } Here's the change that triggers it. --- tzcode2005b/localtime.c Mon Jan 10 07:19:41 2005 +++ tzcode2005c/localtime.c Mon Jan 17 16:36:15 2005 @@ -1441,10 +1436,11 @@ { register const struct state * sp; register int dir; - register int bits; register int i, j; register int saved_seconds; register long li; + register time_t lo; + register time_t hi; long y; time_t newt; time_t t; @@ -1518,28 +1514,49 @@ yourtm.tm_sec = 0; } /* - ** Divide the search space in half - ** (this works whether time_t is signed or unsigned). + ** Do a binary search (this works whatever time_t's type is). */ - bits = TYPE_BIT(time_t) - 1; - /* - ** If time_t is signed, then 0 is just above the median, - ** assuming two's complement arithmetic. - ** If time_t is unsigned, then (1 << bits) is just above the median. - */ - t = TYPE_SIGNED(time_t) ? 0 : (((unsigned long) 1) << bits); + if (!TYPE_SIGNED(time_t)) { + lo = 0; + hi = lo - 1; + } else if (!TYPE_INTEGRAL(time_t)) { + if (sizeof(time_t) > sizeof(float)) + hi = (time_t) DBL_MAX; + else hi = (time_t) FLT_MAX; + lo = -hi; + } else { + lo = 1; + for (i = 0; i < (int) TYPE_BIT(time_t) - 1; ++i) + lo *= 2; + hi = -(lo + 1); + } for ( ; ; ) { - if ((*funcp)(&t, offset, &mytm) == NULL) - return WRONG; /* XXX probably wrong */ - dir = tmcomp(&mytm, &yourtm); + t = lo / 2 + hi / 2; + if (t < lo) + t = lo; + else if (t > hi) + t = hi; + if ((*funcp)(&t, offset, &mytm) == NULL) { + /* + ** Assume that t is too extreme to be represented in + ** a struct tm; arrange things so that it is less + ** extreme on the next pass. + */ + dir = (t > 0) ? 1 : -1; + } else dir = tmcomp(&mytm, &yourtm); if (dir != 0) { - if (bits-- < 0) + if (t == lo) { + ++t; + ++lo; + } else if (t == hi) { + --t; + --hi; + } + if (lo > hi) return WRONG; - if (bits < 0) - --t; /* may be needed if new t is minimal */ - else if (dir > 0) - t -= ((long) 1) << bits; - else t += ((long) 1) << bits; + if (dir > 0) + hi = t; + else lo = t; continue; } if (yourtm.tm_isdst < 0 || mytm.tm_isdst == yourtm.tm_isdst)

1 0

Energy bill signed -- U.S. changes Daylight Saving rules
by Jonathan Lennox Aug. 9, 2005

Aug. 9, 2005

President Bush signed the Energy Policy Act of 2005 today, which among many other things changes the U.S.'s Daylight Saving rules. The full text of the bill is available from thomas.loc.gov (search on bill number "hr6" for the 109th Congress). For the purposes of this list, the relevant section is as follows: SEC. 110. DAYLIGHT SAVINGS. (a) Amendment- Section 3(a) of the Uniform Time Act of 1966 (15 U.S.C. 260a(a)) is amended-- (1) by striking `first Sunday of April' and inserting `second Sunday of March'; and (2) by striking `last Sunday of October' and inserting `first Sunday of November'. (b) Effective Date- Subsection (a) shall take effect 1 year after the date of enactment of this Act or March 1, 2007, whichever is later. (c) Report to Congress- Not later than 9 months after the effective date stated in subsection (b), the Secretary shall report to Congress on the impact of this section on energy consumption in the United States. (d) Right to Revert- Congress retains the right to revert the Daylight Saving Time back to the 2005 time schedules once the Department study is complete. -- Jonathan Lennox lennox(a)cs.columbia.edu

1 0

Mailing list back in business
by Olson, Arthur David (NIH/NCI) Aug. 2, 2005

Aug. 2, 2005

As the appearance of the non-forwarded message from Egmont Koblinger indicates, mail is now getting through to elsie.nci.nih.gov from the outside world. Thanks to all for your patience as bureaucracy central did the necessary work. --ado

1 0

zdump of glibc reports invalid timezone name
by Egmont Koblinger Aug. 2, 2005

Aug. 2, 2005

Hi, I've found an interesting issue. If I compile zdump directly from the tzcode package (any version), it works perfectly. However, if exactly the same source is built within the full glibc tree, that one reports invalid time zone abbreviations. I have no idea whether it's a tzcode or a glibc bug. Please read the full detailed description here: http://sources.redhat.com/bugzilla/show_bug.cgi?id=1140 and please, if possible, also report your comments to this bugzilla, so that I hope you and the glibc team can quickly catch and fix the bug together. Thanks, Egmont

1 0

FW: US DST changes?
by Olson, Arthur David (NIH/NCI) July 23, 2005

July 23, 2005

A reminder: mail to tz(a)elsie.nci.nih.gov is not working (temporarily, I hope). For now, send time-zone stuff to arthur_david_olson(a)nih.gov --ado -----Original Message----- From: John Hawkinson [mailto:jhawk@MIT.EDU] Sent: Friday, July 22, 2005 1:15 PM To: tz via ado Subject: Re: US DST changes? Today's WSJ, p. B4, unbylined, "New Daylight Plan is Cut by One Month." "Under pressure from some business interests, a conference committee working on a compromise energy bill has cut by half a proposed two-month extension of daylight savings time and put off the change until March 2007. "The new plan would advance daylight savings time from the first Sunday of April to the second Sunday in March and extend it an additional week, to the first Sunday in November. The compromise includes a proviso that if the Department of Energy finds serious problems with the measure, which is intended to save electricity use, Congress would have the option to revert back to the current period." ... --jhawk(a)mit.edu John Hawkinson

1 0

FW: FW: US DST changes?
by Olson, Arthur David (NIH/NCI) July 23, 2005

July 23, 2005

A reminder: mail to tz(a)elsie.nci.nih.gov is not working (temporarily, I hope). For now, send time-zone stuff to arthur_david_olson(a)nih.gov --ado -----Original Message----- From: John Hawkinson [mailto:jhawk@MIT.EDU] Sent: Thursday, July 21, 2005 4:07 PM To: arthur_david_olson(a)nih.gov Subject: Re: FW: US DST changes? [ Sent to Arthur, since the list is still down. ftp server works great, though... ] > An article in ran on page D1 of Tuesday's Wall Street Journal, "U.S. > Set to Expand Daylight-Savings Time," discussing the "Energy Policy Act of 2005," > which might extend US DST by 1 month in both directions (Mar-Nov > instead of Apr-Oct). Some updates in the past two days, both in the WSJ. There was a Reuters story on Wednesday, but it seemed very confusing and at-odds with the two SJ stories. Wednesday's WSJ, p. D2, "Daylight-Savings Expansion Plan Is Ripped by Airlines, Churches" by John J. Fialka: "Facing objections from the Bush administration, church groups and others opposed to extending daylight-savings time, House and Senate conferees on the energy bill postponed a decision on the proposal until tomorrow." [i.e. until today, Thursday.] It goes on to cite a letter from the Energy Secretary on behalf of the Bush adminisration requesting the change be dropped because of "serious international harmonization problems for the transportation industry," apparently referring to the coordination of gate slots with Europoean airports, whose DST is currently roughly synchronized with the US's. The article also references church groups who oppose the extension "because it would require children to wait for school buses in the dark." Then, today's WSJ, D2, "Daylight-Savings Plan Might Be Scaled Back," again by Fialka: "The principal sponsor of a proposal to expand daylight-savings time by two months says talks are under way to scale back the change." It goes on to say, "Some senators have complained that the proposed change will be expensive, an issue underscored yesterday as software vendors and utilities arned that computer software and meters with electronic chips that record time will have to be changed, a project that could take years and cost millions of dollars." [Well, ok, that seems excessive.] It then paraphrases David Thewlis of Calconnect.Org, a "consortium of software companies and universities," saying, "the group has no position on the merits of the proposal, which is intended to save energy, but wants Congress to postpone an change until March 2008, to give members and consumers time to make and install the fixes." [Apparently Calconnect.org includes Oracle and Yahoo, as well as MIT and Stanford. Who knew?] --jhawk(a)mit.edu John Hawkinson

1 0

FW: DST for Africa/Tunis
by Olson, Arthur David (NIH/NCI) July 23, 2005

July 23, 2005

A reminder: mail to tz(a)elsie.nci.nih.gov <mailto:tz@elsie.nci.nih.gov> is not working (temporarily, I hope). For now, send time-zone stuff to arthur_david_olson(a)nih.gov <mailto:arthur_david_olson@nih.gov> --ado _____ From: webmaster(a)timezoneconverter.com [mailto:webmaster@timezoneconverter.com] Sent: Thursday, July 21, 2005 3:36 PM To: arthur_david_olson(a)nih.gov Subject: FW: DST for Africa/Tunis I am forwarding this message that I have been trying to send to the list for a few days but was unsuccessful. --Rich Shockney _____ From: webmaster(a)timezoneconverter.com [mailto:webmaster@timezoneconverter.com] Sent: Wednesday, July 20, 2005 12:11 PM To: 'tz(a)lecserver.nci.nih.gov' Cc: 'Arthur David Olson' Subject: DST for Africa/Tunis **Second attempt: The message I sent over the weekend was bounced as undeliverable... I had a site visitor from France state that he had called the Tunisian Embassy and they claimed that Tunis time is the same as France during the Summer. I recall that there was some discussion on this list about whether Tunis would observe DST in 2005. Did this ever get resolved? Is an update needed to the rules for Tunisia? Rich Shockney TimeZoneConverter.com

1 0

Electronic mail challenge
by Olson, Arthur David (NIH/NCI) July 21, 2005

July 21, 2005

As noted in an earlier message today, John Hawkinson reported difficulty sending a message to the mailing list. I've checked elsie's logs; sendmail hasn't logged any messages from outside NIH since July 12th. I'm guessing that something at the NIH firewall changed on that date. I'll investigate further then see if I can resolve the issue with bureaucracy central. In the meantime, please send stuff destined for the time zone list to... arthur_david_olson(a)nih.gov ...and I'll forward it. Thanks! --ado

1 0

FW: US DST changes?
by Olson, Arthur David (NIH/NCI) July 21, 2005

July 21, 2005

John is on the time zone mailing list; I'm checking on why his message did not go through. --ado ----- Forwarded message from John Hawkinson <jhawk(a)MIT.EDU> ----- Date: Wed, 20 Jul 2005 09:59:42 -0400 (EDT) Message-Id: <200507201359.j6KDxfH1002941(a)multics.mit.edu> To: tz(a)elsie.nci.nih.gov Subject: US DST changes? From: John Hawkinson <jhawk(a)MIT.EDU> An article in ran on page D1 of Tuesday's Wall Street Journal, "U.S. Set to Expand Daylight-Savings Time," discussing the "Energy Policy Act of 2005," which might extend US DST by 1 month in both directions (Mar-Nov instead of Apr-Oct). The bill in question was originally H.R.1640 (last year), and is now H.R.6/S.10. The House version includes the DST extension as Section 111.: SEC. 111. DAYLIGHT SAVINGS. (a) Repeal- Section 3(a) of the Uniform Time Act of 1966 (15 U.S.C. 260a(a)) is amended-- (1) by striking `April' and inserting `March'; and (2) by striking `October' and inserting `November'. (b) Report to Congress- Not later than 9 months after the date of enactment of this Act, the Secretary of Energy shall report to Congress on the impact this section on energy consumption in the United States. (text from http://thomas.loc.gov) The Senate version does not include that section. The WSJ article, by John J. Fialka, says, "The idea has now been agreed upon by House and Senate committee staffs, with the approval of both Republican chairmen and ranking Democrats. That means it is likely to be approved by the full House-Senate conference committee, which begins squaring the differences between the House and Senate versions of the bill this week." It would take effect this fall. It seems to me awful fast -- is it reasonable to expect the major OS vendors to update their DST tables in 3 months? [not to mention that the clock doesn't start ticking until the bill is actually signed into law...] --jhawk(a)mit.edu John Hawkinson ----- End forwarded message -----

1 0

Tzcode2005k.tar.gz and tzdata2005k.tar.gz
by Olson, Arthur David (NIH/NCI) July 14, 2005

July 14, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005k.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005k.tar.gz ...are now available. The "leapseconds" file has been edited to reflect the recently announced leap second at the end of 2005. I've also deleted electronic mail addresses from the files as an anti-spam measure. I'm waiting to hear from the heavyweights before incorporating the recent 64-bit stuff (the new version that tacks both 64-bit data and a POSIX TZ string on to the end of traditional timezone data files). --ado

1 0

FW: Bulletin C number 30 (fwd)
by Olson, Arthur David (NIH/NCI) July 5, 2005

July 5, 2005

Long overdue! --ado -----Original Message----- From: Joseph S. Myers [mailto:jsm@polyomino.org.uk] Sent: Monday, July 04, 2005 1:25 PM To: LEAPSECS(a)ROM.USNO.NAVY.MIL; tz(a)lecserver.nci.nih.gov Subject: Bulletin C number 30 (fwd) ---------- Forwarded message ---------- Date: Mon, 4 Jul 2005 15:27:31 +0200 From: "services.iers(a)obspm.fr" <services.iers(a)obspm.fr> To: adresc1(a)callisto.obspm.fr Subject: Bulletin C number 30 INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 4 July 2005 Bulletin C 30 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2006 A positive leap second will be introduced at the end of December 2005. The sequence of dates of the UTC second markers will be: 2005 December 31, 23h 59m 59s 2005 December 31, 23h 59m 60s 2006 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1999 January 1, 0h UTC, to 2006 January 1 0h UTC : UTC-TAI = - 32s from 2006 January 1, 0h UTC, until further notice : UTC-TAI = - 33s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France

2 1

Bulletin C number 30 (fwd)
by Joseph S. Myers July 4, 2005

July 4, 2005

---------- Forwarded message ---------- Date: Mon, 4 Jul 2005 15:27:31 +0200 From: "services.iers(a)obspm.fr" <services.iers(a)obspm.fr> To: adresc1(a)callisto.obspm.fr Subject: Bulletin C number 30 INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 4 July 2005 Bulletin C 30 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2006 A positive leap second will be introduced at the end of December 2005. The sequence of dates of the UTC second markers will be: 2005 December 31, 23h 59m 59s 2005 December 31, 23h 59m 60s 2006 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1999 January 1, 0h UTC, to 2006 January 1 0h UTC : UTC-TAI = - 32s from 2006 January 1, 0h UTC, until further notice : UTC-TAI = - 33s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Time Zone and display
by Jean-Claude OMARY July 1, 2005

July 1, 2005

Sir or Madam, Greetings My name is Jean-Claude Omary. I am writing you from Rio de Janeiro. I found your url from google whilst looking for a time zone service. We are a small Christian church and our web site (www.igrejaprimitiva.com) is under construction. In our website we what to display inside a colon (embed file) the date and time of Rio de Janeiro(Brazil) and Kinshasa (Democratic Republic of Congo). we have got two churches there. On the internet we did not manage to find script that can help us to that. We actually dont know if this service is charged or not. Please let us know. Anyway by this letter we can to ask if you can allow us to link to your website so that in a specific place in our website we can only display those two zone hours and date.What script should we use. We will keep the credit like: "Powered by your business name or your business logo". Your help well be really appreciate. Sincerely yours. Jean-Claude OMARY. Rio de Janeiro Brasil. jcomary(a)igrejaprimitiva.org

1 0