June 2004 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert 25 May '15

25 May '15

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

ftp://elsie.nci.nih.gov/pub/ doesn't work
by Frédéric L. W. Meunier 12 Aug '04

12 Aug '04

I don't know why, but I'm assuming it's because it now rejects connectiong from hosts that don't resolve. Please let me know about any mirrors. -- http://www.pervalidus.net/contact.html

3 2

Re: Georgia abandoning Soviet-era decree time, back to zonal time
by Todd C. Miller 28 Jun '04

28 Jun '04

Comment was wrong in the previous diff (it was based on a BBC news article before I read the Itar-Tass one). - todd Index: asia =================================================================== RCS file: /cvs/src/share/zoneinfo/datfiles/asia,v retrieving revision 1.18 diff -u -r1.18 asia --- asia 28 Jun 2004 13:43:32 -0000 1.18 +++ asia 28 Jun 2004 14:05:32 -0000 @@ -336,6 +336,10 @@ # Instead of putting back clocks at the end of October, Georgia # will stay on daylight savings time this winter to save energy, # President Eduard Shevardnadze decreed Wednesday. +# +# From Peter Galbavy <peter.galbavy(a)knowtion.net> (2004-060-27) +# Georgia has changed its time zone back to that of Moscow today. +# It is now three hours ahead of Greenwich Mean Time. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59:16 - TBMT 1924 May 2 # Tbilisi Mean Time @@ -346,7 +350,8 @@ 3:00 E-EurAsia GE%sT 1994 Sep lastSun 4:00 E-EurAsia GE%sT 1996 Oct lastSun 4:00 1:00 GEST 1997 Mar lastSun - 4:00 E-EurAsia GE%sT + 4:00 E-EurAsia GE%sT 2004 Jun 26 + 3:00 RussiaAsia GE%sT # East Timor

1 0

Georgia abandoning Soviet-era decree time, back to zonal time
by Todd C. Miller 28 Jun '04

28 Jun '04

Reported to me by Peter Galbavy <peter.galbavy(a)knowtion.net> Diff follows the article below (hopefully I got it right). - todd http://www.itar-tass.com/eng/level2.html?NewsID=983466&PageNum=0 Georgia abandoning Soviet-era decree time, back to zonal time 27.06.2004, 02.36 TBILISI, June 27 (Itar-Tass) - Georgia is abandoning the Soviet-era special, or decreed, time and is switching back to its zonal time as of Sunday, June 27. In practical terms, this means that it will now have the same time as Russias Moscow zone and will be three hours ahead of London instead of the former four hours, and two hours ahead of Paris and Berlin instead of the former three. The reverting to the zonal time follows a recent decree by President Mikhail Saakashvili saying the decision on it was taken with due regard of Georgias geographic position, the European integration process, and proposals by the national department for standards and hydrometeorology. The so-called decreed time took effect all across the former USSR from Kamchatka through to Belarus and from the Artic Islands through to southern Turkmenistan June 16, 1930. The measure was aimed at a better us of daylight. Unlike daylight saving time (DST), the decreed time did not shift and was pegged on the principle of zonal time plus an hour round the year. As of 1981, however, the DST was also introduced in the USSR, which meant that from April through October the formula would look like the zonal time plus one hour of the decreed time plus one hour of the DST. Most countries of the former USSR dropped the decreed timed by now and reverted to their zonal time. Russia is one of a few exceptions. Index: asia =================================================================== RCS file: /cvs/src/share/zoneinfo/datfiles/asia,v retrieving revision 1.18 diff -u -r1.18 asia --- asia 28 Jun 2004 13:43:32 -0000 1.18 +++ asia 28 Jun 2004 14:02:18 -0000 @@ -336,6 +336,10 @@ # Instead of putting back clocks at the end of October, Georgia # will stay on daylight savings time this winter to save energy, # President Eduard Shevardnadze decreed Wednesday. +# +# From Peter Galbavy <peter.galbavy(a)knowtion.net> (2004-060-27) +# Georgia has changed its time zone back to that of Moscow today. +# It is now just four hours ahead of Greenwich Mean Time (instead of five). # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59:16 - TBMT 1924 May 2 # Tbilisi Mean Time @@ -346,7 +350,8 @@ 3:00 E-EurAsia GE%sT 1994 Sep lastSun 4:00 E-EurAsia GE%sT 1996 Oct lastSun 4:00 1:00 GEST 1997 Mar lastSun - 4:00 E-EurAsia GE%sT + 4:00 E-EurAsia GE%sT 2004 Jun 26 + 3:00 RussiaAsia GE%sT # East Timor

1 0

Time in Georgia
by Joseph S. Myers 27 Jun '04

27 Jun '04

Seen at <http://news.bbc.co.uk/1/hi/world/europe/3843511.stm>: Times are a' changing in Georgia Georgia moved closer to Western Europe on Sunday - not physically but in terms of time. The former Soviet republic has changed its time zone back to that of Moscow. As a result it is now just four hours ahead of Greenwich Mean Time, rather than five hours ahead. The switch was decreed by the pro-Western president of Georgia, Mikhail Saakashvili, who said the change was partly prompted by the process of integration into Europe. In the 1990s, Georgia switched to five rather than four hours ahead of GMT in an effort to combat the effects of a national energy crisis. The change back means Georgia is now three hours ahead of London and two hours ahead of Paris and Berlin. Georgia is about 1,600km (1,000 miles) south of the Russian capital, but only 400km to the east. -- Joseph S. Myers jsm(a)polyomino.org.uk

1 0

pytz - Python World Timezones
by Stuart Bishop 24 Jun '04

24 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://sourceforge.net/projects/pytz/ pytz is a transformation of the public domain Olsen timezone database into pure Python code. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. This implementation solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). The only remaining inaccuracy is that datetime.strftime only reports the UTC offset to the nearest minute (This is probably a feature - you have to draw a line somewhere). 536 of the Olsen timezones are supported. The missing few are for Riyadh Solar Time in 1987, 1988 and 1989. As Saudi Arabia gave up trying to cope with their timezone definition, I see no reason to complicate my code further to cope with them. (I understand the intention was to set sunset to 0:00 local time, the start of the Islamic day. In the best case caused the DST offset to change daily and worst case caused the DST offset to change each instant depending on how you interpreted the ruling.) Note that if you perform date arithmetic on local times that cross DST boundaries, the results may be in an incorrect timezone (ie. subtract 1 minute from 2002-10-27 1:00 EST and you get 2002-10-27 0:59 EST instead of the correct 2002-10-27 1:59 EDT). This cannot be resolved without modifying the Python datetime implementation. However, these tzinfo classes provide a normalize() method which allows you to correct these values. Installation ============ This is a standard Python distutils distribution. To install the package, run the following command as an administrative user:: python setup.py install License ======= BSD style license. I'm more than happy to relicense this code for inclusion in other open source projects. Example & Usage =============== >>> from datetime import datetime, timedelta >>> from pytz import timezone >>> utc = timezone('UTC') >>> eastern = timezone('US/Eastern') >>> utc_dt = datetime(2002, 10, 27, 6, 0, 0, tzinfo=utc) >>> loc_dt = utc_dt.astimezone(eastern) >>> fmt = '%Y-%m-%d %H:%M:%S %Z (%z)' >>> loc_dt.strftime(fmt) '2002-10-27 01:00:00 EST (-0500)' >>> (loc_dt - timedelta(minutes=10)).strftime(fmt) '2002-10-27 00:50:00 EST (-0500)' >>> eastern.normalize(loc_dt - timedelta(minutes=10)).strftime(fmt) '2002-10-27 01:50:00 EDT (-0400)' >>> (loc_dt + timedelta(minutes=10)).strftime(fmt) '2002-10-27 01:10:00 EST (-0500)' Latest Versions =============== This module will be updated after releases of the Olsen timezone database. The latest version can be downloaded from sourceforge_. .. _sourceforge: http://sourceforge.net/projects/pytz/ Further Reading =============== More info than you want to know about timezones:: http://www.twinsun.com/tz/tz-link.htm Contact ======= Stuart Bishop <stuart(a)stuartbishop.net> - -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA2bWTAfqZj7rGN0oRAjF0AJwMEwGDgODszthhjETIAUqXFSOxfACfbkeH hJh13lBU3ge5UYtes0niQu8= =sEx7 -----END PGP SIGNATURE-----

2 2

Re: Re: 64-bit time_t must go--this is non-negotiable
by WHarms＠bfs.de 23 Jun '04

23 Jun '04

hi list, i see that a log of systems have moved to 64bit time_t (not only native 64bit systems). what happends if zdump move to mytime_t 64bit ? on 32bit that would extend the precission without any effect while 64bit system will be coverred automagicly. (hopes to ease fustration for ado :) walter - - - - - - - - - - - - - - Original Message - - - - - - - - - - - - - - From: Paul Eggert <eggert(a)CS.UCLA.EDU> Subject: Re: 64-bit time_t must go--this is non-negotiable Date: 06/18/04 23:29 Robert Elz <kre(a)munnari.oz.au> writes: > Certainly it isn't correct to simply cite the precedent of some > other (different) change, and act as if that was sufficient > justification for any new change. Sure. But here we've already seen precedent for this exact same change. Lots of operating systems have decided to use 64-bit time_t on 64-bit hosts. They all had their inevitable shakeout period. One (Tru64) distinguishes between time_t and time64_t, the way that ado proposed, but as far as I can tell, nobody else thought that the extra complexity is worth the hassle. These folks have already made their decision, in some cases many years ago, and they're unlikely to change their minds now no matter how much huffing and puffing we do. If we want to write code that is portable to 64-bit GNU/Linux, Solaris, FreeBSD 6, Microsoft Windows, etc., then we have to make sure it works with 64-bit time_t. > I can't imagine wanting to know about times that stretch from 1970 > to 1970 + 2.6 * 10^11, that's just absurd. I agree, and if we had to do it over again I'd design time_t differently, but it's too late to change this for the systems mentioned above.

1 0

Argentina's timezone blues... aftermath
by Mariano Absatz 23 Jun '04

23 Jun '04

Hi, I'm deeply sorry, I had a couple of completely maddening weeks and wasn't able to follow up on my postings... I couldn't even read if someone did... I'm posting old news so, if this has already been posted, please disregard my message (I'm not on my computer right now, and I can't easily access the list archive)... So... I know what's going on, but I couldn't find official sources... The 'official federal source', only says that the 'national' timezone is UTC-03:00 ( http://tinyurl.com/yvhh9 ). These media articles from a major newspaper mostly cover the current state http://www.lanacion.com.ar/04/05/27/de_604825.asp http://www.lanacion.com.ar/04/05/28/de_605203.asp The changes in Mendoza are those that Paul incorporated a couple of weeks ago. The following eight (8) provinces pulled clocks back to UTC-04:00 at midnight Monday May 31st. (that is, the night between 05/31 and 06/01). Catamarca Chubut La Rioja San Juan San Luis Santa Cruz Tierra del Fuego Tucumán Apparently, all nine provinces would go back to UTC-03:00 at the same time in October 17th. Sorry for providing so little info, so late.-- 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 ) )\ ----------------------------------------------------------- The sex was so good that even the neighbors had a cigarette.

3 12

64-bit time_t must go--this is non-negotiable
by Olson, Arthur David (NIH/NCI) 18 Jun '04

18 Jun '04

Given that time_t has been a 32-bit entity since day one of UNIX, there are a slew of binary executables out there that are built on the premise, as well as plenty of values stored in disk files (take UNIX accounting logs, please). That makes it an extremely bad idea to redefine time_t as a 64-bit value. This does not, of course, mean that it's a bad idea to have 64-bit time stamps available--as long as they're available under a different name (along with differently named functions to manipulate them). The historic precedent in the UNIX realm is the addition of the "lseek" system call once files got larger than good old "seek" could handle (even with the provision of seeks where the short-integer seek argument specified a block number rather than a byte number). So somewhere down the road we can expect to see entities such as ltime_t and lgmtime. Bottom line: we should probably not be doing a lot of work to support 64-bit time_t implementations since we don't want to encourage such implementations. --ado

5 5

Time Zone Localizations
by Mark Davis 18 Jun '04

18 Jun '04

The common locale data repository project (CLDR) hosted by the Unicode consortium (www.unicode.org/cldr/) provides for translations of time zone IDs, based on the public domain time zone database at ftp://elsie.nci.nih.gov/pub/. A number of issues have come up concerning those translations, and we have put together a proposal for changing the way that is done. The goal would be to make changes in CLDR 1.1, which would be released around mid-October of this year. The current version of the proposal is at: http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/ti… I'd very much appreciate any feedback on the proposal. Mark __________________________________ http://www.macchiato.com ► शिष्यादिच्छेत्पराजयम् ◄

13 80