- tz - lists.iana.org

Argentina - Mendoza: Changes
by Mariano Absatz May 21, 2004

May 21, 2004

Hi, well, today it was officially published that the Province of Mendoza is changing its timezone this winter... starting tomorrow night. I'm quite in a hurry, but: At midnight Saturday May 22nd, the clocks will be pulled back one hour (from UTC-03:00 to UTC-04:00). At midnight Saturday October 16th, the clocks will get back to UTC-03:00. The Official data is at http://www.gobernac.mendoza.gov.ar/boletin/pdf/20040521-27158-normas.pdf (in Spanish). Regards. -- Mariano Absatz - El Baby mailto:baby@baby.com.ar http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/'> Powered by Pegasus Mail /|__) http://www.pmail.com ) )\ ----------------------------------------------------------- Windows, another fine product from the folks who gave us EDLIN.

1 0

possible changes in Argentina (southamerica)
by Mariano Absatz May 19, 2004

May 19, 2004

Hi, Apparently, the Province of Mendoza, in Argentina's Mid-West, is about to change it's timezone to UTC-04:00 Most of Argentina lies 'geographically' in that tz, but at some point in time, after having implemented UTC-03:00 for the summer, the country 'just stayed there'... what's more, a few years ago, for some time, it used a summer tz of UTC-02:00. As Mendoza is one of the Provinces in the Western border, it is most affected for using a 'more Eastern' tz, and this is especially bad in the (Southern) winter. As there's an Energy crisis in Argentina, Mendoza is trying to 'wake up an hour later'. It remains to be seen if the Province of Mendoza effectively legislates this and what the other Provinces do (especially, the other Provinces in the West). Newspaper info (in Spanish): http://www.lanacion.com.ar/04/05/11/de_600178.asp http://www.clarin.com/diario/2004/05/15/elpais/p-00401.htm http://www1.cronica.com.ar/article/articleview/1084567955/1/20/ http://www.losandes.com.ar/2004/0505/editorial/nota186060_1.htm http://www.losandes.com.ar/2004/0512/economia/nota187333_1.htm I'll keep the list posted as this develops. Regards. -- Mariano Absatz - El Baby mailto:baby@baby.com.ar http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/'> Powered by Pegasus Mail /|__) http://www.pmail.com ) )\

2 2

Time zones from Windows XP
by Ruby Ballen May 18, 2004

May 18, 2004

I am new in this mailing list so, please, forgive me if this has been asked before. I'm trying to map the list of time zones that Windows XP includes, to the correct binary files in tz Database, but I am missing some of them. I just could not find which one to use or if it is supported at all. Here is the list: (GMT - 12:00) International Date Line West (GMT - 06:00) Central America (GMT - 03:00) Brasilia (GMT - 02:00) Mid-Atlantic (GMT + 01:00) West Central Africa (GMT + 06:00) Sri Jayawardenepura (GMT + 13:00) Nuku’alofa Also, is there any site where I can find documentation about this library? Thanks a lot for your help. RBallen

3 2

tzdata 2003e: imperfections
by Oscar van Vlijmen May 18, 2004

May 18, 2004

I found a couple of small imperfections in the tzdata files. asia file: Cyprus is now (May 01, 2004) part of the European Union. In spite of the interesting remarks for Cyprus in the tz data file, the Cyprus entry should be in the europe file. antarctica file: New Zealand: Rules are given, but no Zone information, so no actual time information. All files: GMT is obsolete. UTC should be used. Nearly all files, lots of entries: In some cases DST is no longer observed, but the Zone lines still mention a DST Rule. One example from the asia file (some information omitted by me): # Korea (North and South) ... # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ROK 1960 only - May 15 0:00 1:00 D Rule ROK 1960 only - Sep 13 0:00 0 S Rule ROK 1987 1988 - May Sun<=14 0:00 1:00 D Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Seoul 8:27:52 - LMT 1890 8:30 - KST 1904 Dec 9:00 - KST 1928 8:30 - KST 1932 9:00 - KST 1954 Mar 21 8:00 ROK K%sT 1961 Aug 10 8:30 - KST 1968 Oct 9:00 ROK K%sT ... Since South Korea no longer observes DST, it would be better for the consistency of the database if the last line was changed into: 9:00 ROK K%sT 1988 Oct and an extra line was added, like: 9:00 - KST The software will give the correct time for e.g. this moment I guess, because no Rule line can be found, valid for May 2004. So, changing the database files for this could get a low priority, but it is still an imperfection! Oscar van Vlijmen 2004-05-17

7 11

RE: tzdata 2003e: imperfections (DST rules)
by Olson, Arthur David (NIH/NCI) May 17, 2004

May 17, 2004

> If I am interpreting the documentation correctly, then the last Zone line says that there is a Rule "ROK" in effect, but for dates after Sunday October 09, 1988 no Rule can be found. The last Rule line says that on Sunday October 09, 1988 you should transition out of DST, and that's what the software does. After that, there aren't any transitions specified by Rules, so the software doesn't do anything else. This really is what's supposed to happen; there's no need for a change here. --ado

1 0

Re: tzdata 2003e: imperfections (DST rules)
by Oscar van Vlijmen May 17, 2004

May 17, 2004

> From: "Olson, Arthur David (NIH/NCI)" > Remember that the Rules tell when DST transitions happen; in the above case, > the Rule that's valid is one that specifies the last transition before May > 2004, which is assumed to be in effect in perpetuity. Excerpts from the zic.8 documentation file: " A rule line has the form Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .... TO Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. .... The fields that make up a zone line are: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] .... UNTIL The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a ..... " The Rule and Zone (continuation) lines from the example are: Rule ROK 1987 1988 - Oct Sun<=14 0:00 0 S Zone... 9:00 ROK K%sT If I am interpreting the documentation correctly, then the last Zone line says that there is a Rule "ROK" in effect, but for dates after Sunday October 09, 1988 no Rule can be found. The DST rules were changed, so, strictly speaking, and according to the documentation, there should be a new Zone line. For users of the TZ software there is no problem I guess, but developers who can only use the database files, encounter minor problems interpreting the database. Oscar van Vlijmen 2004-05-17

1 0

RE: tzdata 2003e: imperfections
by Olson, Arthur David (NIH/NCI) May 17, 2004

May 17, 2004

> 9:00 ROK K%sT > ... > > Since South Korea no longer observes DST, it would be better for the consistency of the database if the last line was changed into: > 9:00 ROK K%sT 1988 Oct > and an extra line was added, like: > 9:00 - KST Generally speaking, we want to have the last line of a Zone refer to a Rule line. This is particularly important in cases where a country has multiple time zones. If the country decides in the future to change the way DST is handled (for example, decides to start observing DST again), we can make things right by changing one Rule rather than by changing multiple Zones. > The software will give the correct time for e.g. this moment I guess, because no Rule line can be found, valid for May 2004. > So, changing the database files for this could get a low priority, but it is still an imperfection! Remember that the Rules tell when DST transitions happen; in the above case, the Rule that's valid is one that specifies the last transition before May 2004, which is assumed to be in effect in perpetuity. --ado

1 0

Change in Mongolian daylight saving time
by Ganbold April 17, 2004

April 17, 2004

Hello, Current rule settings for Mongolia in /usr/src/share/zoneinfo/asia is wrong. It should be changed from: ... Rule Mongol 2001 only - Apr 27 2:00s 1:00 S Rule Mongol 2001 only - Sep 28 2:00s 0 - ... To the following: ... Rule Mongol 2001 only - Mar lastSat 2:00s 1:00 S Rule Mongol 2001 only - Sep lastSat 2:00s 0 - ... Daylight saving occurs at 02:00 local time last Saturday of March. It will changes back to normal at 02:00 local time last Saturday of September. Please make appropriate changes. Please let me know if you have any questions. sincerely, Ganbold Ts. Mongolia

2 5

Mass media article on leap seconds
by Olson, Arthur David (NIH/NCI) April 15, 2004

April 15, 2004

The 2004-03 issue of the U.S. monthly "Discover" has an article titled "Leap Seconds" by Karen Wright(pages 42-45, but the first two pages are décor and an introductory blurb). No mention of the Big Secret (that leap seconds have not been inserted since January of 1999). The article states that "...computer software designers haven't adapted very well to the occasional added second, so experts in air traffic control, satellite communications, and electronic fund transfers have been lobbying to abolish the tinkering. A leap second may have caused the Russian satellite navigation system to crash for hours, and critics claim the added instants could cause commercial airliners to crash as well." The article also notes a couple of modest proposals: "Leap seconds could be inserted every four years along with the February leap day...or leap minutes could be added every half century or so." (Either proposal, if adopted, would require changes in both POSIX and the public-domain time zone code.) Your correspondent's two cents: in setting up the time handling in UNIX, T&R got it exactly right with respect to springing forward and falling back when DST goes in to and out of effect--keep the computer counting monotonically and leave it to the software to translate the monotonic count into a representation of local time. What's right at the level of an hour is also right at the level of a second--keep the computer counting at one count per second, and leave it to software to figure out what should be displayed when the user asks what time it is. --ado

6 8

Re: ICU and "Sources for Time Zone and Daylight Saving Time Data"
by Paul Eggert April 13, 2004

April 13, 2004

"Steven R. Loomis" <srl(a)jtcsv.com> writes: > Java 1.4 has historical time zones (I believe also from the tz > data?) Thanks for letting me know about this. I looked through the source code (in J2SE-1.4.2/java/src.zip) for this. As far as I can tell, the historical time zone data is in J2SE-1.4.2/j2se/jre/lib/zi, in a format that differs somewhat from the standard Olson format. Also, this information is not in every Java 1.4 implementation, though it is in Sun's. I can't find any supported way to convert from tz format to Java format, so if the Java data are wrong there doesn't seem to be any way to update them from the tz master. Does the following snippet summarize this information correctly? <li><a href="http://java.sun.com/">Sun Java</a> releases since 1.4 contain a copy of a recent <samp>tz</samp> database in a Java-specific format.</li>

2 2