- tz - lists.iana.org

RE: Definition of time_t changed from signed to unsigned...
by Olson, Arthur David (NIH/NCI) July 15, 2004

July 15, 2004

> -----Original Message----- > From: Chris Richards [mailto:cj_richards@hotmail.com] > Sent: Tuesday, July 13, 2004 12:42 PM > To: Olson, Arthur David (NIH/NCI) > Subject: RE: Definition of time_t changed from signed to unsigned... > > > Hi, > > Actually, could this be due to me using a tz.cfg database that was compiled > in an environment where time_t was typedef'ed differently to the environment > which loads and uses the tz.cfg? It certainly could be due to using a signed-system-generated data file on an unsigned-time_t system. Signed time values from before 1970 are negative numbers; on an unsigned system they'll look like large positive numbers. This means that for present-day time_t values the "t < sp->ats[0]" test will be satisfied, the software will assume that it's dealing with a time predating the first transition that's recorded, and the software will apply "default" rules. "localtime.c" could be jiggered to ignore pre-1970 transitions if (1) time_t is unsigned and (2) a data file has been generated on a signed system (which can be determined by seeing if the transition times are correctly sorted from the perspective of the system on which the software is being run). Given the notes on this mailing list about the inadvisability of unsigned time_t's, such jiggering is of questionable value. --ado

1 0

Re: Dust settled on Argentina?
by Paul Eggert July 13, 2004

July 13, 2004

"Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > I haven't seen another patch. Should I go ahead and promulgate the > 2004-06-15 patch, or should I wait? Sorry, I dropped the ball on that one. Here's a revised version: it incorporates the discussion to earlier revisions of all the patches I've posted. I also updated the tz-link.htm web page to reflect foreign web site changes. * Patches relevant to current time stamps. - Major reorganizaton for Argentina. . New zones America/Argentina/Tucuman, America/Argentina/La_Rioja, America/Argentina/San_Juan, America/Argentina/ComodRivadavia, America/Argentina/Rio_Gallegos, America/Argentina/Ushuaia reflecting this year's changes. (Thanks to Mariano Absatz and Gwillim Law for their dogged reporting of this info.) . America/Buenos_Aires renamed to America/Argentina/Buenos_Aires, and similarly for America/Cordoba, America/Jujuy, America/Catamarca, America/Mendoza. Backward-compatible links retained so that old TZ settings still work. - Georgia switched to Moscow time on June 27. (Thanks to Joseph S. Myers for this info.) * Patch relevant to historical time stamps. - Where new zones were created, I recorded Shanks's opinions of what happened to Argentina in 1991. * Patch due to ISO 3166 change. - The ISO added a country code AX for the Aaland Islands, so I added a new link Europe/Mariehamn for AX. * Documentation patches. - Add URL for PyTZ. - Update URL for Tru64. - Remove dangling URL to <http://www.hilink.com.au/times/>. - Mention that Java has only a subset of the Olson database. - Move ICU localization reference to "Time Notation" section. - Update names for Astrodienst, worldtimezone.com, INMS. * Some proposed source-code patches for 64-bit hosts. - Use 'long' when computing years, not 'int', to avoid spurious overflow on 64-bit hosts. - Use our (more generous) asctime implementation than relying on the system asctime, so that we can print years before 1900 and after 9999 (even on HP-UX). - When localtime/gmtime fails, print the raw time_t value as an integer than the less-informative "NULL". - Don't attempt to print out all the 64-bit time_t space, as that will take nearly forever; instead, default to printing a few decades into the future, and don't bother to print times before about 1833. This suffices for all the current tz data and is good enough for POSIX tz values until the year 2106. We can revisit this when we add true 64-bit support for tz data. diff -pru tz-2004aa/asia tz/asia --- tz-2004aa/asia 2004-05-27 09:00:30.000000000 -0700 +++ tz/asia 2004-07-13 13:16:45.000000000 -0700 @@ -335,6 +335,16 @@ Link Asia/Nicosia Europe/Nicosia # 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 the BBC via Joseph S. Myers (2004-06-27): +# +# Georgia moved closer to Western Europe on Sunday... 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. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tbilisi 2:59:16 - LMT 1880 2:59:16 - TBMT 1924 May 2 # Tbilisi Mean Time @@ -345,7 +355,8 @@ Zone Asia/Tbilisi 2:59:16 - LMT 1880 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 27 + 3:00 RussiaAsia GE%sT # East Timor diff -pru tz-2004aa/backward tz/backward --- tz-2004aa/backward 2004-05-27 09:00:30.000000000 -0700 +++ tz/backward 2004-06-14 12:30:06.845824000 -0700 @@ -4,9 +4,14 @@ # and their old names. Many names changed in late 1993. Link America/Adak America/Atka +Link America/Argentina/Buenos_Aires America/Buenos_Aires +Link America/Argentina/Catamarca America/Catamarca +Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Indianapolis America/Fort_Wayne +Link America/Argentina/Jujuy America/Jujuy Link America/Indiana/Knox America/Knox_IN +Link America/Argentina/Mendoza America/Mendoza Link America/Rio_Branco America/Porto_Acre Link America/Cordoba America/Rosario Link America/St_Thomas America/Virgin diff -pru tz-2004aa/europe tz/europe --- tz-2004aa/europe 2004-05-27 09:00:30.000000000 -0700 +++ tz/europe 2004-06-12 18:37:32.547326000 -0700 @@ -921,6 +921,10 @@ Zone Europe/Helsinki 1:39:52 - LMT 1878 2:00 Finland EE%sT 1981 Mar 29 2:00 2:00 EU EE%sT +# Aaland Is +Link Europe/Helsinki Europe/Mariehamn + + # France # From Ciro Discepolo (2000-12-20): diff -pru tz-2004aa/iso3166.tab tz/iso3166.tab --- tz-2004aa/iso3166.tab 2003-12-15 06:36:37.000000000 -0800 +++ tz/iso3166.tab 2004-06-13 23:50:45.657245000 -0700 @@ -2,11 +2,11 @@ # # @(#)iso3166.tab 1.14 # -# From Paul Eggert <eggert(a)twinsun.com> (2003-02-04): +# From Paul Eggert <eggert(a)twinsun.com> (2004-06-14): # # This file contains a table with the following columns: # 1. ISO 3166-1 alpha-2 country code, current as of -# ISO 3166-1 Newsletter No. V-8 (2003-07-23). See: +# ISO 3166-1 Newsletter No. V-10 (2004-04-26). See: # <a href="http://www.iso.org/iso/en/prods-services/iso3166ma/index.html"> # ISO 3166 Maintenance agency (ISO 3166/MA) # </a>. @@ -36,6 +36,7 @@ AS Samoa (American) AT Austria AU Australia AW Aruba +AX Aaland Islands AZ Azerbaijan BA Bosnia & Herzegovina BB Barbados diff -pru tz-2004aa/southamerica tz/southamerica --- tz-2004aa/southamerica 2004-05-27 09:00:30.000000000 -0700 +++ tz/southamerica 2004-06-22 21:39:13.762385000 -0700 @@ -155,17 +155,47 @@ Rule Arg 2000 only - Mar Sun>=1 0:00 0 - # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks. +# +# From Mariano Absatz (2004-06-05): +# 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 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). +# Apparently, all nine provinces would go back to UTC-03:00 at the same +# time in October 17th. +# +# Catamarca, Chubut, La Rioja, San Juan, San Luis, Santa Cruz, +# Tierra del Fuego, Tucuman. +# +# From Mariano Absatz (2004-06-14): +# ... this weekend, the Province of Tucuman decided it'd go back to UTC-03:00 +# yesterday midnight (that is, at 24:00 Saturday 12th), since the people's +# annoyance with the change is much higher than the power savings obtained.... +# +# From Gwillim Law (2004-06-14): +# http://www.lanacion.com.ar/04/06/10/de_609078.asp ... +# "The time change in Tierra del Fuego was a conflicted decision from +# the start. The government had decreed that the measure would take +# effect on June 1, but a normative error forced the new time to begin +# three days earlier, from a Saturday to a Sunday.... +# Our understanding was that the change was originally scheduled to take place +# on June 1 at 00:00 in Chubut, Santa Cruz, Tierra del Fuego (and some other +# provinces). Sunday was May 30, only two days earlier. So the article +# contains a contradiction. I would give more credence to the Saturday/Sunday +# date than the "three days earlier" phrase, and conclude that Tierra del +# Fuego set its clocks back at 2004-05-30 00:00. # Unless otherwise specified, data are from Shanks through 1992, from # the IATA otherwise. As noted below, Shanks says that -# America/Cordoba split into 7 subregions during 1991/1992, but we +# America/Cordoba split into 6 subregions during 1991/1992, but we # haven't verified this yet so for now we'll keep it a single region. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] # -# Buenos Aires (BA), Capital Federal (CF), Santa Cruz (SC), -# Tierra del Fuego, Antartida e Islas del Atlantico Sur (TF) -Zone America/Buenos_Aires -3:53:48 - LMT 1894 Oct 31 +# Buenos Aires (BA), Capital Federal (CF), +Zone America/Argentina/Buenos_Aires -3:53:48 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May # Cordoba Mean Time -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 @@ -174,24 +204,19 @@ Zone America/Buenos_Aires -3:53:48 - LMT -3:00 - ART # # Santa Fe (SF), Entre Rios (ER), Corrientes (CN), Misiones (MN), Chaco (CC), -# Formosa (FM), Salta (SA), Tucuman (TM), Santiago del Estero (SE), -# Cordoba (CB), La Rioja (LR), San Juan (SJ), San Luis (SL), La Pampa (LP), -# Neuquen (NQ), Rio Negro (RN), Chubut (CH) +# Formosa (FM), Salta (SA), Santiago del Estero (SE), Cordoba (CB), +# San Luis (SL), La Pampa (LP), Neuquen (NQ), Rio Negro (RN) # # Shanks also makes the following claims, which we haven't verified: # - Formosa switched to -3:00 on 1991-01-07. -# - La Rioja and San Juan switched to -4:00 on 1991-03-01 -# and then to -3:00 on 1991-05-07. # - Misiones switched to -3:00 on 1990-12-29. # - Chaco switched to -3:00 on 1991-01-04. # - San Luis switched to -4:00 on 1990-03-14, then to -3:00 on 1990-10-15, # then to -4:00 on 1991-03-01, then to -3:00 on 1991-06-01. # - Santiago del Estero switched to -4:00 on 1991-04-01, # then to -3:00 on 1991-04-26. -# If we need to add Zones for these areas, we may need to have a subdirectory -# for Argentina, as e.g. "America/San_Luis" is too ambiguious. # -Zone America/Cordoba -4:16:48 - LMT 1894 Oct 31 +Zone America/Argentina/Cordoba -4:16:48 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 @@ -201,8 +226,47 @@ Zone America/Cordoba -4:16:48 - LMT 1894 -4:00 Arg AR%sT 2000 Mar 3 -3:00 - ART # +# Tucuman (TM) +Zone America/Argentina/Tucuman -4:20:52 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Mar 3 + -4:00 - WART 1991 Oct 20 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 13 + -3:00 - ART +# +# La Rioja (LR) +Zone America/Argentina/La_Rioja -4:27:24 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Mar 1 + -4:00 - WART 1991 May 7 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 20 + -3:00 - ART +# +# San Juan (SJ) +Zone America/Argentina/San_Juan -4:34:04 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Mar 1 + -4:00 - WART 1991 May 7 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Oct 17 + -3:00 - ART +# # Jujuy (JY) -Zone America/Jujuy -4:21:12 - LMT 1894 Oct 31 +Zone America/Argentina/Jujuy -4:21:12 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 @@ -216,7 +280,7 @@ Zone America/Jujuy -4:21:12 - LMT 1894 O -3:00 - ART # # Catamarca (CT) -Zone America/Catamarca -4:23:08 - LMT 1894 Oct 31 +Zone America/Argentina/Catamarca -4:23:08 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 @@ -224,10 +288,12 @@ Zone America/Catamarca -4:23:08 - LMT 18 -4:00 - WART 1991 Oct 20 -3:00 Arg AR%sT 1999 Oct 3 -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 20 -3:00 - ART # # Mendoza (MZ) -Zone America/Mendoza -4:35:16 - LMT 1894 Oct 31 +Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 @@ -242,6 +308,42 @@ Zone America/Mendoza -4:35:16 - LMT 1894 -3:00 - ART 2004 May 23 -4:00 - WART 2004 Oct 17 -3:00 - ART +# +# Chubut (CH) +# The name "Comodoro Rivadavia" exceeds the 14-byte POSIX limit. +Zone America/Argentina/ComodRivadavia -4:30:00 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Mar 3 + -4:00 - WART 1991 Oct 20 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 20 + -3:00 - ART +# +# Santa Cruz (SC) +Zone America/Argentina/Rio_Gallegos -4:36:52 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May # Cordoba Mean Time + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 20 + -3:00 - ART +# +# Tierra del Fuego, Antartida e Islas del Atlantico Sur (TF) +Zone America/Argentina/Ushuaia -4:33:12 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May # Cordoba Mean Time + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 May 30 + -4:00 - WART 2004 Jun 20 + -3:00 - ART # Aruba # Zone NAME GMTOFF RULES FORMAT [UNTIL] diff -pru tz-2004aa/tz-link.htm tz/tz-link.htm --- tz-2004aa/tz-link.htm 2004-05-27 09:00:30.000000000 -0700 +++ tz/tz-link.htm 2004-07-13 13:21:17.651768000 -0700 @@ -9,7 +9,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"' /> <meta name="DC.Creator" content="Eggert, Paul" /> <meta name="DC.Contributor" content="Olson, Arthur David" /> -<meta name="DC.Date" content="2004-05-24" /> +<meta name="DC.Date" content="2004-07-13" /> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time" /> <meta name="DC.Identifier" content="http://www.twinsun.com/tz/tz-link.htm" /> @@ -47,7 +47,7 @@ including <a href="http://www.apple.com/macosx/">Mac OS X</a>, <a href="http://h71000.www7.hp.com/">OpenVMS</a>, <a href="http://wwws.sun.com/software/solaris/">Solaris</a>, -<a href="http://www.tru64unix.compaq.com/">Tru64</a>, and +<a href="http://h30097.www3.hp.com/">Tru64</a>, and <a href="http://www.sco.com/products/unixware/">UnixWare</a>.</p> <p> Each location in the database represents a national region where all @@ -104,14 +104,9 @@ is a text-based point-and-click interfac throughout the world.</li> <li>Fancier web interfaces, roughly in ascending order of complexity, include: <ul> -<li><a href="http://www.hilink.com.au/times/">Local Times Around the -World</a></li> <li><a href="http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP">Current Time in 1000 Places</a></li> <li><a href="http://timezoneconverter.com/">Time Zone Converter</a></li> </ul></li> -<li><a href="http://www.holidayfestival.com/">The Worldwide Holiday -& Festival Site</a> lists DST-related clock changes along with -holidays.</li> <li><a href="http://www.timeanddate.com/worldclock/">The World Clock - Time Zones</a> is a web interface to a time zone database derived from @@ -152,9 +147,8 @@ contains a script <code>parse_olson</cod <code>tz</code> source into <a href="http://www.perl.org/">Perl</a> modules. It is part of the Perl <a href="http://datetime.perl.org/">DateTime Project</a>, which is freely -available under both the GPL and the Perl <a -href="http://www.perl.com/language/misc/Artistic.html">Artistic -License</a>. DateTime::TimeZone also contains a script +available under both the GPL and the Perl Artistic +License. DateTime::TimeZone also contains a script <code>tests_from_zdump</code> that generates test cases for each clock transition in the <code>tz</code> database.</li> <li><a href="http://oss.software.ibm.com/icu/">International Components for @@ -166,6 +160,10 @@ and time API</a> contains a class <code>org.joda.time.tz.ZoneInfoCompiler</code> that compiles <code>tz</code> source into a Joda-specific binary format. Joda Time is freely available under a BSD-style license.</li> +<li><a href="http://sourceforge.net/projects/pytz/">PyTZ - Python Time +Zone Library</a> compiles <code>tz</code> source into +<a href="http://www.python.org/">Python</a>. +It is freely available under a BSD-style license.</li> </ul> <h2>Other <code>tz</code> binary file readers</h2> <ul> @@ -180,15 +178,14 @@ and is widely used in GNU/Linux systems. is a <code>tz</code> binary file reader written in Java. It is freely available under the GNU LGPL.</li> <li><a href="http://s.keim.free.fr/tz/doc.html">Python time zones</a> -is a <code>tz</code> binary file reader written in <a -href="http://www.python.org/">Python</a>. It is freely available -under a BSD-style license.</li> +is a <code>tz</code> binary file reader written in Python. +It is freely available under a BSD-style license.</li> </ul> <h2>Other <code>tz</code>-based time zone conversion software</h2> <ul> <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> +contain a copy of a subset of a recent <samp>tz</samp> database in a +Java-specific format.</li> <li><a href="http://www1.tip.nl/~t876506/AboutTimeZonesHC.html">HyperCard time zones calculator</a> is a HyperCard stack.</li> @@ -198,8 +195,8 @@ Microsoft Windows program.</li> </ul> <h2>Other time zone databases</h2> <ul> -<li><a href="http://www.astro.com/cgi-bin/atlw3/aq.cgi?lang=e">Atlas Query -- Astrodienst</a> is Astrodienst's Web version of Shanks's +<li><a href="http://www.astro.com/cgi/aq.cgi?lang=e">Atlas Query</a> +is Astrodienst's Web version of Shanks's excellent time zone history atlases published in both <a href="http://astrocom.com/software/pcatlas.php">computer</a> and <a href="http://astrocom.com/books/xrefa.php#SHANKS">book</a> form by <a @@ -217,7 +214,7 @@ for the <code>usno*</code> files in the <li><a href="http://www.airportcitycodes.com/aaa/">Airlines, Airplanes and Airports</a> lists current standard times for thousands of airports around the world. This seems to be derived from -the <a href="http://www.iata.org/sked/publications/">Standard +the <a href="http://www.iata.org/ps/publications/9179.htm">Standard Schedules Information Manual (SSIM)</a> of the the <a href="http://www.iata.org/">International Air Transport Association</a>, @@ -238,8 +235,8 @@ recent editions. The pictorial quality is good, but the maps do not indicate summer time, and parts of the data are a few years out of date.</li> -<li><a href="http://worldtimezone.com/">World timezones map with -current time</a> +<li><a href="http://worldtimezone.com/">Current time around the world +and standard time zones map of the world</a> has several fancy time zone maps; it covers Russia particularly well. The maps' pictorial quality is not quite as good as the CIA's but the maps are more up to date.</li> @@ -252,9 +249,7 @@ boundaries between time zones within cou <li>Manifold.net's <a href="http://www.manifold.net/download/freemaps.html">Free Maps and GIS Data</a> includes a Manifold-format map of world time zone -boundaries distributed under the GPL. The GeoCommunity's <a -href="http://software.geocomm.com/data/intl_timezones.html">International -Time Zones</a> publishes the same data in other formats.</li> +boundaries distributed under the GPL.</li> <li>The US Geological Survey's National Atlas of the United States publishes the <a href="http://www.nationalatlas.gov/timeznm.html">Time Zones of the United States</a> in the public domain.</li> @@ -304,7 +299,7 @@ Portuguese)</a>.</dd> <dd>The Institute for National Measurement Standards publishes current and some older information about <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/daylight_savings_e.html">Time -Zones and Daylight Saving Time</a>.</dd> +Zones & Daylight Saving Time</a>.</dd> <dt>Chile</dt> <dd>WebExhibits publishes a <a href="http://webexhibits.org/daylightsaving/chile.html" @@ -420,6 +415,12 @@ protocols.</li> <a href="http://www.exit109.com/~ghealton/y2k/yrexamples.html">The Best of Dates, the Worst of Dates</a> covers many problems encountered by software developers when handling dates and time stamps.</li> +<li><a +href="http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/ti…">Time +Zone Localization</a> is a proposed mechanism for localizing time zone +labels and abbreviations; for example, one might use it to specify +Russian translations for "Eastern European Summer Time", "EEST", and +<code>Europe/Bucharest</code>.</li> <li> Alphabetic time zone abbreviations should not be used as unique identifiers for UTC offsets as they are ambiguous in practice. For diff -pru tz-2004aa/zone.tab tz/zone.tab --- tz-2004aa/zone.tab 2003-10-06 06:32:21.000000000 -0700 +++ tz/zone.tab 2004-06-22 21:35:35.301478000 -0700 @@ -41,11 +41,17 @@ AQ -6617+11031 Antarctica/Casey Casey St AQ -7824+10654 Antarctica/Vostok Vostok Station, S Magnetic Pole AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Base, Terre Adelie AQ -690022+0393524 Antarctica/Syowa Syowa Station, E Ongul I -AR -3436-05827 America/Buenos_Aires E Argentina (BA, DF, SC, TF) -AR -3124-06411 America/Cordoba most locations (CB,CC,CH,CN,ER,FM,LP,LR,MN,NQ,RN,SA,SE,SF,SJ,SL,TM) -AR -2411-06518 America/Jujuy Jujuy (JY) -AR -2828-06547 America/Catamarca Catamarca (CT) -AR -3253-06849 America/Mendoza Mendoza (MZ) +AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) +AR -3124-06411 America/Argentina/Cordoba most locations (CB, CC, CN, ER, FM, LP, MN, NQ, RN, SA, SE, SF, SL) +AR -2411-06518 America/Argentina/Jujuy Jujuy (JY) +AR -3124-06411 America/Argentina/Tucuman Tucuman (TM) +AR -2828-06547 America/Argentina/Catamarca Catamarca (CT) +AR -2926-06651 America/Argentina/La_Rioja La Rioja (LR) +AR -3132-06831 America/Argentina/San_Juan San Juan (SJ) +AR -3253-06849 America/Argentina/Mendoza Mendoza (MZ) +AR -4552-06730 America/Argentina/ComodRivadavia Chubut (CH) +AR -5138-06913 America/Argentina/Rio_Gallegos Santa Cruz (SC) +AR -5448-06818 America/Argentina/Ushuaia Tierra del Fuego (TF) AS -1416-17042 Pacific/Pago_Pago AT +4813+01620 Europe/Vienna AU -3133+15905 Australia/Lord_Howe Lord Howe Island @@ -59,6 +65,7 @@ AU -3455+13835 Australia/Adelaide South AU -1228+13050 Australia/Darwin Northern Territory AU -3157+11551 Australia/Perth Western Australia AW +1230-06858 America/Aruba +AX +6006+01957 Europe/Mariehamn AZ +4023+04951 Asia/Baku BA +4352+01825 Europe/Sarajevo BB +1306-05937 America/Barbados diff -pru tz-2004aa/asctime.c tz/asctime.c --- tz-2004aa/asctime.c 1998-05-28 06:56:06.000000000 -0700 +++ tz/asctime.c 2004-06-14 21:23:43.000000000 -0700 @@ -41,14 +41,14 @@ char * buf; else mn = mon_name[timeptr->tm_mon]; /* ** The X3J11-suggested format is - ** "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %d\n" - ** Since the .2 in 02.2d is ignored, we drop it. + ** "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n" + ** Use "%02d", as it is a bit more portable than "%.2d". */ - (void) sprintf(buf, "%.3s %.3s%3d %02d:%02d:%02d %d\n", + (void) sprintf(buf, "%.3s %.3s%3d %02d:%02d:%02d %ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, - TM_YEAR_BASE + timeptr->tm_year); + timeptr->tm_year + (long) TM_YEAR_BASE); return buf; } diff -pru tz-2004aa/date.c tz/date.c --- tz-2004aa/date.c 2001-10-09 10:31:31.000000000 -0700 +++ tz/date.c 2004-06-14 22:44:08.703969000 -0700 @@ -630,8 +630,12 @@ const time_t t; time_t outt; tm = *localtime(&t); - cent = (tm.tm_year + TM_YEAR_BASE) / 100; - year_in_cent = (tm.tm_year + TM_YEAR_BASE) - cent * 100; + cent = tm.tm_year / 100 + TM_YEAR_BASE / 100; + year_in_cent = tm.tm_year % 100; + if (year_int_cent < 0) { + cent--; + year_in_cent += 100; + } month = tm.tm_mon + 1; day = tm.tm_mday; hour = tm.tm_hour; diff -pru tz-2004aa/localtime.c tz/localtime.c --- tz-2004aa/localtime.c 2003-12-15 06:36:35.000000000 -0800 +++ tz/localtime.c 2004-06-14 23:11:00.519250000 -0700 @@ -134,8 +134,11 @@ static void gmtsub P((const time_t * ti static void localsub P((const time_t * timep, long offset, struct tm * tmp)); static int increment_overflow P((int * number, int delta)); +static int long_increment_overflow P((long * number, int delta)); static int normalize_overflow P((int * tensptr, int * unitsptr, int base)); +static int long_normalize_overflow P((long * tensptr, + int * unitsptr, int base)); static void settzname P((void)); static time_t time1 P((struct tm * tmp, void(*funcp) P((const time_t *, @@ -1149,7 +1152,7 @@ register struct tm * const tmp; register const struct lsinfo * lp; register long days; register long rem; - register int y; + register long y; register int yleap; register const int * ip; register long corr; @@ -1218,7 +1221,7 @@ register struct tm * const tmp; y = EPOCH_YEAR; #define LEAPS_THRU_END_OF(y) ((y) / 4 - (y) / 100 + (y) / 400) while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) { - register int newy; + register long newy; newy = y + days / DAYSPERNYEAR; if (days < 0) @@ -1294,6 +1297,18 @@ int delta; } static int +long_increment_overflow(number, delta) +long * number; +int delta; +{ + long number0; + + number0 = *number; + *number += delta; + return (*number < number0) != (delta < 0); +} + +static int normalize_overflow(tensptr, unitsptr, base) int * const tensptr; int * const unitsptr; @@ -1309,6 +1324,21 @@ const int base; } static int +long_normalize_overflow(tensptr, unitsptr, base) +long * const tensptr; +int * const unitsptr; +const int base; +{ + register int tensdelta; + + tensdelta = (*unitsptr >= 0) ? + (*unitsptr / base) : + (-1 - (-1 - *unitsptr) / base); + *unitsptr -= tensdelta * base; + return long_increment_overflow(tensptr, tensdelta); +} + +static int tmcomp(atmp, btmp) register const struct tm * const atmp; register const struct tm * const btmp; @@ -1336,6 +1366,8 @@ const int do_norm_secs; register int dir; register int bits; register int i, j ; + register long li; + long y; register int saved_seconds; time_t newt; time_t t; @@ -1352,42 +1384,46 @@ const int do_norm_secs; return WRONG; if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; - if (normalize_overflow(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR)) + y = yourtm.tm_year; + if (long_normalize_overflow(&y, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* - ** Turn yourtm.tm_year into an actual year number for now. + ** Turn y into an actual year number for now. ** It is converted back to an offset from TM_YEAR_BASE later. */ - if (increment_overflow(&yourtm.tm_year, TM_YEAR_BASE)) + if (long_increment_overflow(&y, TM_YEAR_BASE)) return WRONG; while (yourtm.tm_mday <= 0) { - if (increment_overflow(&yourtm.tm_year, -1)) + if (long_increment_overflow(&y, -1)) return WRONG; - i = yourtm.tm_year + (1 < yourtm.tm_mon); - yourtm.tm_mday += year_lengths[isleap(i)]; + li = y + (1 < yourtm.tm_mon); + yourtm.tm_mday += year_lengths[isleap(li)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { - i = yourtm.tm_year + (1 < yourtm.tm_mon); - yourtm.tm_mday -= year_lengths[isleap(i)]; - if (increment_overflow(&yourtm.tm_year, 1)) + li = y + (1 < yourtm.tm_mon); + yourtm.tm_mday -= year_lengths[isleap(li)]; + if (long_increment_overflow(&y, 1)) return WRONG; } for ( ; ; ) { - i = mon_lengths[isleap(yourtm.tm_year)][yourtm.tm_mon]; + i = mon_lengths[isleap(y)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; yourtm.tm_mday -= i; if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; - if (increment_overflow(&yourtm.tm_year, 1)) + if (long_increment_overflow(&y, 1)) return WRONG; } } - if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) + if (long_increment_overflow(&y, -TM_YEAR_BASE)) + return WRONG; + yourtm.tm_year = y; + if (yourtm.tm_year != y) return WRONG; if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) saved_seconds = 0; - else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { + else if (y < EPOCH_YEAR - TM_YEAR_BASE) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. diff -pru tz-2004aa/strftime.c tz/strftime.c --- tz-2004aa/strftime.c 2001-10-04 14:01:17.000000000 -0700 +++ tz/strftime.c 2004-06-14 22:37:47.213984000 -0700 @@ -108,6 +108,7 @@ static const struct lc_time_T C_time_loc static char * _add P((const char *, char *, const char *)); static char * _conv P((int, const char *, char *, const char *)); +static char * _lconv P((long, const char *, char *, const char *)); static char * _fmt P((const char *, const struct tm *, char *, const char *, int *)); size_t strftime P((char *, size_t, const char *, const struct tm *)); @@ -210,8 +211,12 @@ label: ** something completely different. ** (ado, 1993-05-24) */ - pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, - "%02d", pt, ptlim); + { + int c = (TM_YEAR_BASE / 100 + + t->tm_year / 100 + - (t->tm_year % 100 < 0)); + pt = _conv(c, "%02d", pt, ptlim); + } continue; case 'c': { @@ -379,12 +384,13 @@ label: ** (ado, 1996-01-02) */ { - int year; + long year; int yday; int wday; int w; - year = t->tm_year + TM_YEAR_BASE; + year = t->tm_year; + year += TM_YEAR_BASE; yday = t->tm_yday; wday = t->tm_wday; for ( ; ; ) { @@ -436,10 +442,13 @@ label: pt = _conv(w, "%02d", pt, ptlim); else if (*format == 'g') { + int g = year % 100; + if (g < 0) + g += 100; *warnp = IN_ALL; - pt = _conv(year % 100, "%02d", + pt = _conv(g, "%02d", pt, ptlim); - } else pt = _conv(year, "%04d", + } else pt = _lconv(year, "%04ld", pt, ptlim); } continue; @@ -476,13 +485,17 @@ label: } continue; case 'y': + { + int y = t->tm_year % 100; + if (y < 0) + y += 100; *warnp = IN_ALL; - pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, - "%02d", pt, ptlim); + pt = _conv(y, "%02d", pt, ptlim); + } continue; case 'Y': - pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", - pt, ptlim); + pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, + "%04ld", pt, ptlim); continue; case 'Z': #ifdef TM_ZONE @@ -586,6 +599,19 @@ const char * const ptlim; } static char * +_lconv(n, format, pt, ptlim) +const long n; +const char * const format; +char * const pt; +const char * const ptlim; +{ + char buf[INT_STRLEN_MAXIMUM(long) + 1]; + + (void) sprintf(buf, format, n); + return _add(buf, pt, ptlim); +} + +static char * _add(str, pt, ptlim) const char * str; char * pt; diff -pru tz-2004aa/zdump.8 tz/zdump.8 --- tz-2004aa/zdump.8 2003-09-16 04:12:41.000000000 -0700 +++ tz/zdump.8 2004-06-17 13:33:33.238073000 -0700 @@ -40,6 +40,12 @@ otherwise. .TP .BI "\-c " cutoffyear Cut off the verbose output near the start of the given year. +By default, verbose output is cut off a few decades after the +current date and time. .SH "SEE ALSO" newctime(3), tzfile(5), zic(8) +.SH "BUGS" +Time discontinuities are detected via a heuristic that suffices for +all historically valid discontinuities, but one can construct +artificial time zones for which the heuristic fails. .\" @(#)zdump.8 7.4 diff -pru tz-2004aa/zdump.c tz/zdump.c --- tz-2004aa/zdump.c 2003-09-16 04:12:41.000000000 -0700 +++ tz/zdump.c 2004-06-17 14:12:10.425374000 -0700 @@ -6,6 +6,7 @@ static char elsieid[] = "@(#)zdump.c 7.3 ** You can use this code to help in verifying other implementations. */ +#include "limits.h" /* for CHAR_BIT */ #include "stdio.h" /* for stdout, stderr, perror */ #include "string.h" /* for strcpy */ #include "sys/types.h" /* for time_t */ @@ -24,6 +25,25 @@ static char elsieid[] = "@(#)zdump.c 7.3 #define FALSE 0 #endif /* !defined FALSE */ +#ifndef TYPE_BIT +#define TYPE_BIT(type) (sizeof (type) * CHAR_BIT) +#endif /* !defined TYPE_BIT */ + +#ifndef TYPE_SIGNED +#define TYPE_SIGNED(type) (((type) -1) < 0) +#endif /* !defined TYPE_SIGNED */ + +#ifndef INT_STRLEN_MAXIMUM +/* +** 302 / 1000 is log10(2.0) rounded up. +** Subtract one for the sign bit if the type is signed; +** add one for integer division truncation; +** add one more for a minus sign if the type is signed. +*/ +#define INT_STRLEN_MAXIMUM(type) \ + ((TYPE_BIT(type) - TYPE_SIGNED(type)) * 302 / 1000 + 1 + TYPE_SIGNED(type)) +#endif /* !defined INT_STRLEN_MAXIMUM */ + #ifndef EXIT_SUCCESS #define EXIT_SUCCESS 0 #endif /* !defined EXIT_SUCCESS */ @@ -56,10 +76,18 @@ static char elsieid[] = "@(#)zdump.c 7.3 #define TM_YEAR_BASE 1900 #endif /* !defined TM_YEAR_BASE */ +#ifndef DAYSPERWEEK +#define DAYSPERWEEK 7 +#endif /* !defined DAYSPERWEEK */ + #ifndef DAYSPERNYEAR #define DAYSPERNYEAR 365 #endif /* !defined DAYSPERNYEAR */ +#ifndef MONSPERYEAR +#define MONSPERYEAR 12 +#endif /* !defined MONSPERYEAR */ + #ifndef isleap #define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0) #endif /* !defined isleap */ @@ -128,6 +156,9 @@ static long delta P((struct tm * newp, s static time_t hunt P((char * name, time_t lot, time_t hit)); static size_t longest; static char * progname; +static char * my_asctime_r P((const struct tm *, char *)); +static char * my_asctime P((const struct tm *)); +static void showtime P((time_t, const struct tm *)); static void show P((char * zone, time_t t, int v)); int @@ -139,17 +170,19 @@ char * argv[]; register int c; register int vflag; register char * cutoff; - register int cutyear; - register long cuttime; + register long cutyear; + long y; + register time_t lasttime; char ** fakeenv; time_t now; time_t t; time_t newt; time_t hibit; + time_t time_t_min; + time_t time_t_max; struct tm tm; - struct tm newtm; + struct tm * newtm; - INITIALIZE(cuttime); #if HAVE_GETTEXT - 0 (void) setlocale(LC_MESSAGES, ""); #ifdef TZ_DOMAINDIR @@ -176,22 +209,44 @@ _("%s: usage is %s [ --version ] [ -v ] argv[0], argv[0]); (void) exit(EXIT_FAILURE); } + for (hibit = 1; (hibit << 1) != 0; hibit <<= 1) + continue; + time_t_max = ~((time_t) 0); + if (TYPE_SIGNED(time_t)) + time_t_max &= ~hibit; + time_t_min = TYPE_SIGNED(time_t) ? hibit : 0; + (void) time(&now); if (cutoff != NULL) { - int y; - - cutyear = atoi(cutoff); - cuttime = 0; - for (y = EPOCH_YEAR; y < cutyear; ++y) - cuttime += DAYSPERNYEAR + isleap(y); - cuttime *= SECSPERHOUR * HOURSPERDAY; + cutyear = atol(cutoff); + } else { + /* + ** By default, the cutoff is the maximum time value, + ** or a few decades from now, whichever comes first. + ** This prevents us from generating too much output if + ** time_t is wider than 32 bits. + */ + newtm = gmtime (&now); + if (newtm == NULL) + cutyear = now < 0 ? LONG_MIN : LONG_MAX; + else { + cutyear = newtm->tm_year + (long) TM_YEAR_BASE; + cutyear = 2050 + 100 * ((cutyear - 1930) / 100); + } + } + lasttime = 0; + for (y = EPOCH_YEAR; y < cutyear; ++y) { + newt = lasttime - !lasttime; + newt += (DAYSPERNYEAR + isleap(y)) * SECSPERHOUR * HOURSPERDAY; + if (newt < lasttime) { + lasttime = time_t_max; + break; + } + lasttime = newt; } - (void) time(&now); longest = 0; for (i = optind; i < argc; ++i) if (strlen(argv[i]) > longest) longest = strlen(argv[i]); - for (hibit = 1; (hibit << 1) != 0; hibit <<= 1) - continue; { register int from; register int to; @@ -224,40 +279,47 @@ _("%s: usage is %s [ --version ] [ -v ] /* ** Get lowest value of t. */ - t = hibit; - if (t > 0) /* time_t is unsigned */ - t = 0; + t = time_t_min; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); + /* + ** But don't go below - 2**32 in the following loop, + ** as that predates standard time, would cause us to + ** generate too much output, and could dump core if + ** localtime returns NULL. The earliest known use of + ** standard time is 1837 (Iceland) and - 2**32 is a + ** bit before that. + */ + if ((t + 1) / 2 < -2147483647) { + t = -1 - 2147483647; + t *= 2; + } tm = *localtime(&t); (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); for ( ; ; ) { - if (cutoff != NULL && t >= cuttime) + if (lasttime < t) break; newt = t + SECSPERHOUR * 12; - if (cutoff != NULL && newt >= cuttime) + if (lasttime < newt) break; if (newt <= t) break; - newtm = *localtime(&newt); - if (delta(&newtm, &tm) != (newt - t) || - newtm.tm_isdst != tm.tm_isdst || - strcmp(abbr(&newtm), buf) != 0) { + newtm = localtime(&newt); + if (newtm == NULL) + break; + if (delta(newtm, &tm) != (newt - t) || + newtm->tm_isdst != tm.tm_isdst || + strcmp(abbr(newtm), buf) != 0) { newt = hunt(argv[i], t, newt); - newtm = *localtime(&newt); - (void) strncpy(buf, abbr(&newtm), + newtm = localtime(&newt); + (void) strncpy(buf, abbr(newtm), (sizeof buf) - 1); } t = newt; - tm = newtm; + tm = *newtm; } - /* - ** Get highest value of t. - */ - t = ~((time_t) 0); - if (t < 0) /* time_t is signed */ - t &= ~hibit; + t = time_t_max; t -= SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; @@ -323,7 +385,7 @@ struct tm * oldp; return -delta(oldp, newp); result = 0; for (tmy = oldp->tm_year; tmy < newp->tm_year; ++tmy) - result += DAYSPERNYEAR + isleap(tmy + TM_YEAR_BASE); + result += DAYSPERNYEAR + isleap(tmy + (long) TM_YEAR_BASE); result += newp->tm_yday - oldp->tm_yday; result *= HOURSPERDAY; result += newp->tm_hour - oldp->tm_hour; @@ -334,6 +396,80 @@ struct tm * oldp; return result; } +/* +** my_asctime_r and my_asctime are stolen from asctime.c. Unlike +** Standard C asctime, my_asctime has well-defined behavior even if +** the year is less than -999 or greater than 9999. +*/ + +static char * +my_asctime_r(timeptr, buf) +register const struct tm * timeptr; +char * buf; +{ + static const char wday_name[][3] = { + "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" + }; + static const char mon_name[][3] = { + "Jan", "Feb", "Mar", "Apr", "May", "Jun", + "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" + }; + register const char * wn; + register const char * mn; + + if (timeptr->tm_wday < 0 || timeptr->tm_wday >= DAYSPERWEEK) + wn = "???"; + else wn = wday_name[timeptr->tm_wday]; + if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) + mn = "???"; + else mn = mon_name[timeptr->tm_mon]; + /* + ** The X3J11-suggested format is + ** "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n" + ** Use "%02d", as it is a bit more portable than "%.2d". + */ + (void) sprintf(buf, "%.3s %.3s%3d %02d:%02d:%02d %ld\n", + wn, mn, + timeptr->tm_mday, timeptr->tm_hour, + timeptr->tm_min, timeptr->tm_sec, + timeptr->tm_year + (long) TM_YEAR_BASE); + return buf; +} + +static char * +my_asctime(timeptr) +register const struct tm * timeptr; +{ + /* + ** Big enough for something such as + ** ??? ???-2147483648 -2147483648:-2147483648:-2147483648 -2147483648\n + ** (two three-character abbreviations, five strings denoting integers, + ** three explicit spaces, two explicit colons, a newline, + ** and a trailing ASCII nul). + */ + static char result[3 * 2 + 5 * INT_STRLEN_MAXIMUM(int) + + 3 + 2 + 1 + 1]; + + return my_asctime_r(timeptr, result); +} + +static void +showtime(t, timeptr) +time_t t; +const struct tm * timeptr; +{ + if (timeptr != NULL) { + const char *p; + for (p = my_asctime (timeptr); *p != '\n'; p++) + putchar (*p); + } else { + if (TYPE_SIGNED(time_t)) + printf ("%ld\n", (long) t); + else + printf ("%lu\n", (unsigned long) t); + } +} + static void show(zone, t, v) char * zone; @@ -343,13 +479,15 @@ int v; struct tm * tmp; (void) printf("%-*s ", (int) longest, zone); - if (v) - (void) printf("%.24s UTC = ", asctime(gmtime(&t))); + if (v) { + showtime(t, gmtime(&t)); + (void) printf(" UTC = "); + } tmp = localtime(&t); - (void) printf("%.24s", asctime(tmp)); + showtime(t, tmp); if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); - if (v) { + if (v && tmp != NULL) { (void) printf(" isdst=%d", tmp->tm_isdst); #ifdef TM_GMTOFF (void) printf(" gmtoff=%ld", tmp->TM_GMTOFF); @@ -365,7 +503,7 @@ struct tm * tmp; register char * result; static char nada; - if (tmp->tm_isdst != 0 && tmp->tm_isdst != 1) + if (!tmp || (tmp->tm_isdst != 0 && tmp->tm_isdst != 1)) return &nada; result = tzname[tmp->tm_isdst]; return (result == NULL) ? &nada : result;

1 0

RE: Definition of time_t changed from signed to unsigned...
by Olson, Arthur David (NIH/NCI) July 13, 2004

July 13, 2004

> The problem is that the timezone subsystem seems to expect time_t to be signed. There are a number of functions that only work if time_t is signed. > E.g. function localsub() in file localtime.c. The presence of the comment... /* ** 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. */ ...is a reminder that some effort went into ensuring that the stuff in localtime.c would work whether time_t was signed or unsigned. I'd love to get details on what's going wrong with localsub when time_t is unsigned. --ado

1 0

Re: Need to use unix TZ timezone strings in java Timezone class
by Paul Eggert July 12, 2004

July 12, 2004

"Agarwal, Preeti (Med, GEMS-IT)" <Preeti.Agarwal(a)med.ge.com> writes: > java.util.TimeZone tz = java.util.TimeZone.getTimeZone("EST5EDT"); > > However this sets tz to GMT with 0 offset. How do I get the correct java > timezone? Soemthing like "America/New_york" that I can use to get the > current time in that timezone. I don't know of any Java facility to do that. My previous message gave you a way of generating a table that maps strings like "EST5EDT" to strings like "America/New_York", by looking for "Link" lines in the tz database source files. You could generate this table by hand and drop it into your Java source code somewhere. The idea is that you modify your Java program to look up nonstandard strings like "EST5EDT" in your own table. For that particular example, you'd find an entry in your own table that says "America/New_York", and then use "America/New_York" instead.

1 0

FW: Need to use unix TZ timezone strings in java Timezone class
by Olson, Arthur David (NIH/NCI) July 12, 2004

July 12, 2004

Preeti Agarwal is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Agarwal, Preeti (Med, GEMS-IT) [mailto:Preeti.Agarwal@med.ge.com] Sent: Thursday, July 08, 2004 5:14 PM To: 'tz(a)elsie.nci.nih.gov' Subject: Need to use unix TZ timezone strings in java Timezone class Hi, We have an application that uses the unix timezone string formats "EST5EDT", "PST8PDT" etc. I need to convert these timezone strings into equivalent java timezones that can be understood by java.util.TimeZone class. If I pass the above unix timezone strings, it returns the server timezone and not the java equivalent of the unix timezone. I would appreciate any help in resolving this. Thanks, Preeti

2 1

Need to use unix TZ timezone strings in java Timezone class
by Agarwal, Preeti (Med, GEMS-IT) July 8, 2004

July 8, 2004

Hi, We have an application that uses the unix timezone string formats "EST5EDT", "PST8PDT" etc. I need to convert these timezone strings into equivalent java timezones that can be understood by java.util.TimeZone class. If I pass the above unix timezone strings, it returns the server timezone and not the java equivalent of the unix timezone. I would appreciate any help in resolving this. Thanks, Preeti

1 0

Re: Georgia abandoning Soviet-era decree time, back to zonal time
by Todd C. Miller June 28, 2004

June 28, 2004

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 June 28, 2004

June 28, 2004

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 June 27, 2004

June 27, 2004

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 June 24, 2004

June 24, 2004

-----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 June 24, 2004

June 24, 2004

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 June 23, 2004

June 23, 2004

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) June 18, 2004

June 18, 2004

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 June 18, 2004

June 18, 2004

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

Re: 64-bit time_t must go--this is non-negotiable
by Paul Eggert June 18, 2004

June 18, 2004

matthew green <mrg(a)eterna.com.au> writes: > actually, no NetBSD platform uses a 64 bit time_t on any of the > several 64 bit machines it runs on. Sorry, my mistake. Thanks for correcting me. I was told in 1995 that NetBSD on Alpha used a 64-bit time_t, and never bothered to check (nor has anyone else corrected me despite my reporting this on Usenet for almost a decade, e.g., see <http://groups.google.com/groups?selm=51ke97%2452d%40deck.twinsun.com>). I just checked Usenet, and FreeBSD started talking about the change to 64-bit time_t in 2001 and decided to do it one architecture at a time (sparc64 made the transition earlier this year). They're even making noises about using 64-bit time_t for x86, though that sounds a bit extreme. So I should have written "FreeBSD on some architectures" rather than "the BSDs".

2 1

RE: zdump -v crashes with 64-bit time_t
by Olson, Arthur David (NIH/NCI) June 17, 2004

June 17, 2004

> * Don't attempt to print out all the 64-bit time_t space, as that will > take nearly forever; instead, default to printing about 50 years > into the future, and don't bother to print times before about 1833. It might be better to cut off at something such as... 2050 + 100 * ((current_year - 1930) / 100) ...to ease regression testing; this would maintain a cutoff of 2050 until 2030, then boost the cutoff to 2150 until 2130, and so on. This way zdump output only changes every hundred years; the next change is set for eight years before 2038 and the miseries associated with T4G (you read the abbreviation here first) to provide ample time to catch bugs, while avoiding any output changes for the next 26 years. --ado

2 1

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Monday, June 14, 2004 2:21 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Probably I've given you a confusing example. It's not related to Japanese locale at all. Since Paul and others have given another examples, like "Pacific War Time". I don't think I'd need to give additional examples. It is confusing to produce *correct* (past) local time with the current time zone name as if the current GMT offset and DST rules were applied to the local time. Thanks, Masayoshi Mark Davis wrote: >I am just not quite understanding what you are getting at. In CLDR, the >English translation of the TZID Asia/Singapore would be in the en >locale data; the Japanese translation of TZID Asia/Singapore would be in the ja locale file, etc. >(Note: we don't necessarily have the data for everything yet, but the >LDML format allows all of that.) > >The best I can make out, it sounds like what you want would be the 1942 >Japanese names for the TZID Asia/Singapore, etc.. While it would >certainly be possible to do that with CLDR by providing a variant >locale (ja-JP-1942), it seems rather odd. When I generate a date right >now, and the date happens to be in the past at some time, I don't >generate it with the conventions that would have applied in *on that >date* (unless I am doing a historical novel, for example). I don't >write 1624-1-15 as "The Fifteenth Day of January in the Year of Our >Lord Nineteen-Hundred Four-and-Twenty", or whatever would have been >accepted usage at the time: I write it (in en_US) as "January 15th, 1624" (or some other modern equivalent). > >So I must still be misunderstanding you. > >(Also, we looked at using the Olson TZID abbreviations, but they don't >appear to have wide currency -- people in the countries in question >didn't seem to be familiar with them -- so we decided not to use them.) > >Mark > >(BTW, I will be on a trip next week, and won't be able to reply very >often on this subject) > >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > >----- Original Message ----- >From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)lecserver.nci.nih.gov> >Sent: Sun, 2004 Jun 13 05:36 >Subject: Re: Time Zone Localizations > > >Probably *my* comment wasn't clear enough for you. But I believe that >I've been talking about the same thing as what was pointed out by Paul >(the second bullet of Message-id: <87isdxxm5a.fsf(a)penguin.cs.ucla.edu>). >I *am* talking about the names part, not the computing part. > >For example, Java is capable of *computing* correct local time as of >1942-02-16 in Asia/Singapore. However, since Java has only the last >time zone (display) names (i.e., "Singapore Time" and "SGT" for >Asia/Singapore), Java date/time formatting produces "Singapore Time" or >"SGT" for 1942-02-16, which should be "Japan Standard Time" or "JST". >(tzcode is capable of producing correct abbreviations. But I didn't >think that abbreviation only support for historic names was appropriate >for Java and I didn't add them in 1.4.) I see the same issue in the >LDML spec in <timeZoneNames> as Java currently has. > >My earlier comment included the following which may explain what I'd >like to see in the LDML spec. > ><timeZoneNames> > <zone type="America/Los_Angeles" > > <zoneNameSet format="SGT"> > <long> > <generic>Singapore Time</generic> > ... > </long> > <short> > <generic>SGT</generic> > ... > </short> > </zoneNameSet> > ... > <zoneNameSet format="LMT"> > <long> > <generic>Local Mean Time</generic> > ... > </long> > <short> > <generic>LMT</generic> > ... > </short> > </zoneNameSet> > </zone> >... ></timeZoneNames> > >The format="..." may be problematic. But I haven't thought out any real >syntax for the requirement. > >Thanks, >Masayoshi > > >Mark Davis wrote: > > > >>I think we may be talking past one another. LDML provide for a way to >> >> >*localize* > > >>the Olson TZIDs. For example, you can localize the term >>"Asia/Singapore". That latter ID is the thing that identifies a timezone. >> >>It does not at all attempt to provide an alternative to *computing* >>the results of applying the Olson TZID to any given point in time. >>That is left to the implementation of the Olson time zone database. >>There is no need, nor desire, >> >> >to > > >>duplicate that in the LDML. >> >>As far as we are concerned, 'historic' time zone support simply means >>the ability for the time zone computation to reflect differences in >>behavior that existed in the past but no longer exist. An >>implementation that was only >> >> >limited > > >>to 'modern' time zones (like Windows, or older Java or ICU) would not >>be able >> >> >to > > >>distinguish between two zones that have the same behavior now, but >>differed at some time in the past. So the Olson time zone database >>encompasses historic >> >> >time > > >>zones, and has historic time zone IDs that LDML allows people to >>attach localizations to. >> >>Is that clearer? >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >>----- Original Message ----- >>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)lecserver.nci.nih.gov> >>Sent: Sat, 2004 Jun 12 07:35 >>Subject: Re: Time Zone Localizations >> >> >>It's strange. I responded to your message about 13 hours ago, but it >>doesn't show up yet... Let me try again (with a short version). >> >>I believe you misunderstood my first question. It's simply an invalid >>assumption that a zone (in the Olson zoneinfo) represents a single >>time zone. How do you describe the following with the LDML spec, for example? >> >># Zone NAME GMTOFF RULES FORMAT [UNTIL] >>Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 >> 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. >> 7:00 - MALT 1933 Jan 1 # Malaya Time >> 7:00 0:20 MALST 1936 Jan 1 >> 7:20 - MALT 1941 Sep 1 >> 7:30 - MALT 1942 Feb 16 >> 9:00 - JST 1945 Sep 12 >> 7:30 - MALT 1965 Aug 9 # independence >> 7:30 - SGT 1982 Jan 1 # Singapore Time >> 8:00 - SGT >> >>If the given date is, for example, 1942-02-16, the local time zone >>name has to be "JST" (in the short form). I didn't think LDML would >>allow for defining historical time zone names. I didn't mean >>"historical" tome zone *IDs*. (I really don't understand "modern" and >>"historical" in your message, though. All of (most of?) the zones are >>modern. They just have their own history. And we just don't know what >>will happen to zones in the future. What you think is "modern" today might be "historical" >>tomorrow.) >> >>Thanks, >>Masayoshi >> >>Mark Davis wrote: >> >> >> >> >> >>>I don't know where you are getting that. They are *not* user-defined >>>IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs >>>as matching the >>> >>> >>> >>> >>IDs >> >> >> >> >>>in ftp://elsie.nci.nih.gov/pub/. See also >>>http://www.unicode.org/cldr/data_formats.html#Display_Names also. >>> >>>Mark >>>__________________________________ >>>http://www.macchiato.com >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>>----- Original Message ----- >>>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>Cc: <tz(a)lecserver.nci.nih.gov> >>>Sent: Fri, 2004 Jun 11 08:41 >>>Subject: Re: Time Zone Localizations >>> >>> >>>Mark Davis wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Actually, this is directly related, since LDML is the format used for CLDR. >>>>However, the comment is based on a misunderstanding: LDML currently >>>>does >>>> >>>> >allow > > >>>>for translation of *all* of the timezone IDs, modern and historical. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I guess you don't translate timezone IDs... Anyway, do you mean that >>>LDML allows users to define DTD? (Sorry if this is not a correct way >>>to talk about XML...) So the syntax of <zone> is really user-defined? >>> >>>Thanks, >>>Masayoshi >>> >>> >>> >>> >>> >>> >>> >>>>The problems we are trying to address with this proposal are that >>>>the sheer volume of translations is difficult to manage, *and* many >>>>languages just >>>> >>>> >don't > > >>>>have corresponding terms. And we didn't give guidance before as to >>>>which IDs were the most important to translate, so the translations >>>>that are in CLDR >>>> >>>> >>>> >>>> >>were >> >> >> >> >>>>not done in any kind of priority order. >>>> >>>>Mark >>>>__________________________________ >>>>http://www.macchiato.com >>>>► शिष्यादिच्छेत्पराजयम् ◄ >>>> >>>>----- Original Message ----- >>>>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>>Cc: <tz(a)lecserver.nci.nih.gov> >>>>Sent: Fri, 2004 Jun 11 06:43 >>>>Subject: Re: Time Zone Localizations >>>> >>>> >>>>This is a bit off from the proposal, but related to time zone localizations. >>>> >>>>It appears that the Locale Data Markup Language spec for >>>><timeZoneNames> >>>>(http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes >>>>that a time zone has a single set of long and short names, which >>>>assumption is not valid if a system supports historical time zone changes. >>>>Actually, the time zone support in Java has this problem because it >>>>supports historical changes since 1.4 and always display the "latest" >>>>time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but >>>>I couldn't due to another commitment. >>>> >>>>Is it possible for CLDR to make corrections to the <timeZoneNames> >>>>spec so that it can represent all historical name changes? >>>> >>>>Thanks, >>>>-- >>>>Masayoshi Okutsu >>>>Java Internationalization >>>>Sun Microsystems (K.K.) >>>> >>>>Mark Davis wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>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/forma >>>>>tting/tim >>>>> >>>>> >e > > >>>>> >>>>> >>_ >> >> >> >> >>>>> >>>>> >>>z >>> >>> >>> >>> >>> >>> >>>>> >>>>> >>>>one_localization.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>I'd very much appreciate any feedback on the proposal. >>>>> >>>>>Mark >>>>>__________________________________ >>>>>http://www.macchiato.com >>>>>► शिष्यादिच्छेत्पराजयम् ◄ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Sunday, June 13, 2004 8:37 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Probably *my* comment wasn't clear enough for you. But I believe that I've been talking about the same thing as what was pointed out by Paul (the second bullet of Message-id: <87isdxxm5a.fsf(a)penguin.cs.ucla.edu>). I *am* talking about the names part, not the computing part. For example, Java is capable of *computing* correct local time as of 1942-02-16 in Asia/Singapore. However, since Java has only the last time zone (display) names (i.e., "Singapore Time" and "SGT" for Asia/Singapore), Java date/time formatting produces "Singapore Time" or "SGT" for 1942-02-16, which should be "Japan Standard Time" or "JST". (tzcode is capable of producing correct abbreviations. But I didn't think that abbreviation only support for historic names was appropriate for Java and I didn't add them in 1.4.) I see the same issue in the LDML spec in <timeZoneNames> as Java currently has. My earlier comment included the following which may explain what I'd like to see in the LDML spec. <timeZoneNames> <zone type="America/Los_Angeles" > <zoneNameSet format="SGT"> <long> <generic>Singapore Time</generic> ... </long> <short> <generic>SGT</generic> ... </short> </zoneNameSet> ... <zoneNameSet format="LMT"> <long> <generic>Local Mean Time</generic> ... </long> <short> <generic>LMT</generic> ... </short> </zoneNameSet> </zone> ... </timeZoneNames> The format="..." may be problematic. But I haven't thought out any real syntax for the requirement. Thanks, Masayoshi Mark Davis wrote: >I think we may be talking past one another. LDML provide for a way to >*localize* the Olson TZIDs. For example, you can localize the term >"Asia/Singapore". That latter ID is the thing that identifies a timezone. > >It does not at all attempt to provide an alternative to *computing* the >results of applying the Olson TZID to any given point in time. That is >left to the implementation of the Olson time zone database. There is no >need, nor desire, to duplicate that in the LDML. > >As far as we are concerned, 'historic' time zone support simply means >the ability for the time zone computation to reflect differences in >behavior that existed in the past but no longer exist. An >implementation that was only limited to 'modern' time zones (like >Windows, or older Java or ICU) would not be able to distinguish between >two zones that have the same behavior now, but differed at some time in >the past. So the Olson time zone database encompasses historic time >zones, and has historic time zone IDs that LDML allows people to attach localizations to. > >Is that clearer? > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > >----- Original Message ----- >From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)lecserver.nci.nih.gov> >Sent: Sat, 2004 Jun 12 07:35 >Subject: Re: Time Zone Localizations > > >It's strange. I responded to your message about 13 hours ago, but it >doesn't show up yet... Let me try again (with a short version). > >I believe you misunderstood my first question. It's simply an invalid >assumption that a zone (in the Olson zoneinfo) represents a single time >zone. How do you describe the following with the LDML spec, for example? > ># Zone NAME GMTOFF RULES FORMAT [UNTIL] >Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 > 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. > 7:00 - MALT 1933 Jan 1 # Malaya Time > 7:00 0:20 MALST 1936 Jan 1 > 7:20 - MALT 1941 Sep 1 > 7:30 - MALT 1942 Feb 16 > 9:00 - JST 1945 Sep 12 > 7:30 - MALT 1965 Aug 9 # independence > 7:30 - SGT 1982 Jan 1 # Singapore Time > 8:00 - SGT > >If the given date is, for example, 1942-02-16, the local time zone name >has to be "JST" (in the short form). I didn't think LDML would allow >for defining historical time zone names. I didn't mean "historical" >tome zone *IDs*. (I really don't understand "modern" and "historical" >in your message, though. All of (most of?) the zones are modern. They >just have their own history. And we just don't know what will happen to >zones in the future. What you think is "modern" today might be "historical" >tomorrow.) > >Thanks, >Masayoshi > >Mark Davis wrote: > > > >>I don't know where you are getting that. They are *not* user-defined >>IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs >>as matching the >> >> >IDs > > >>in ftp://elsie.nci.nih.gov/pub/. See also >>http://www.unicode.org/cldr/data_formats.html#Display_Names also. >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >>----- Original Message ----- >>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)lecserver.nci.nih.gov> >>Sent: Fri, 2004 Jun 11 08:41 >>Subject: Re: Time Zone Localizations >> >> >>Mark Davis wrote: >> >> >> >> >> >>>Actually, this is directly related, since LDML is the format used for CLDR. >>>However, the comment is based on a misunderstanding: LDML currently >>>does allow for translation of *all* of the timezone IDs, modern and historical. >>> >>> >>> >>> >>> >>> >>I guess you don't translate timezone IDs... Anyway, do you mean that >>LDML allows users to define DTD? (Sorry if this is not a correct way >>to talk about XML...) So the syntax of <zone> is really user-defined? >> >>Thanks, >>Masayoshi >> >> >> >> >> >>>The problems we are trying to address with this proposal are that the >>>sheer volume of translations is difficult to manage, *and* many >>>languages just don't have corresponding terms. And we didn't give >>>guidance before as to which IDs were the most important to translate, >>>so the translations that are in CLDR >>> >>> >were > > >>>not done in any kind of priority order. >>> >>>Mark >>>__________________________________ >>>http://www.macchiato.com >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>>----- Original Message ----- >>>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>>Cc: <tz(a)lecserver.nci.nih.gov> >>>Sent: Fri, 2004 Jun 11 06:43 >>>Subject: Re: Time Zone Localizations >>> >>> >>>This is a bit off from the proposal, but related to time zone localizations. >>> >>>It appears that the Locale Data Markup Language spec for >>><timeZoneNames> >>>(http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes >>>that a time zone has a single set of long and short names, which >>>assumption is not valid if a system supports historical time zone changes. >>>Actually, the time zone support in Java has this problem because it >>>supports historical changes since 1.4 and always display the "latest" >>>time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but >>>I couldn't due to another commitment. >>> >>>Is it possible for CLDR to make corrections to the <timeZoneNames> >>>spec so that it can represent all historical name changes? >>> >>>Thanks, >>>-- >>>Masayoshi Okutsu >>>Java Internationalization >>>Sun Microsystems (K.K.) >>> >>>Mark Davis wrote: >>> >>> >>> >>> >>> >>> >>> >>>>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/format >>>>ting/time >>>> >>>> >_ > > >>>> >>>> >>z >> >> >> >> >>>> >>>> >>>one_localization.html >>> >>> >>> >>> >>> >>> >>>>I'd very much appreciate any feedback on the proposal. >>>> >>>>Mark >>>>__________________________________ >>>>http://www.macchiato.com >>>>► शिष्यादिच्छेत्पराजयम् ◄ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Saturday, June 12, 2004 10:35 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations It's strange. I responded to your message about 13 hours ago, but it doesn't show up yet... Let me try again (with a short version). I believe you misunderstood my first question. It's simply an invalid assumption that a zone (in the Olson zoneinfo) represents a single time zone. How do you describe the following with the LDML spec, for example? # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT If the given date is, for example, 1942-02-16, the local time zone name has to be "JST" (in the short form). I didn't think LDML would allow for defining historical time zone names. I didn't mean "historical" tome zone *IDs*. (I really don't understand "modern" and "historical" in your message, though. All of (most of?) the zones are modern. They just have their own history. And we just don't know what will happen to zones in the future. What you think is "modern" today might be "historical" tomorrow.) Thanks, Masayoshi Mark Davis wrote: >I don't know where you are getting that. They are *not* user-defined >IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs >as matching the IDs in ftp://elsie.nci.nih.gov/pub/. See also >http://www.unicode.org/cldr/data_formats.html#Display_Names also. > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > >----- Original Message ----- >From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)lecserver.nci.nih.gov> >Sent: Fri, 2004 Jun 11 08:41 >Subject: Re: Time Zone Localizations > > >Mark Davis wrote: > > > >>Actually, this is directly related, since LDML is the format used for CLDR. >>However, the comment is based on a misunderstanding: LDML currently >>does allow for translation of *all* of the timezone IDs, modern and historical. >> >> >> >> >I guess you don't translate timezone IDs... Anyway, do you mean that >LDML allows users to define DTD? (Sorry if this is not a correct way to >talk about XML...) So the syntax of <zone> is really user-defined? > >Thanks, >Masayoshi > > > >>The problems we are trying to address with this proposal are that the >>sheer volume of translations is difficult to manage, *and* many >>languages just don't have corresponding terms. And we didn't give >>guidance before as to which IDs were the most important to translate, >>so the translations that are in CLDR were not done in any kind of priority order. >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >>----- Original Message ----- >>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)lecserver.nci.nih.gov> >>Sent: Fri, 2004 Jun 11 06:43 >>Subject: Re: Time Zone Localizations >> >> >>This is a bit off from the proposal, but related to time zone localizations. >> >>It appears that the Locale Data Markup Language spec for >><timeZoneNames> >>(http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes >>that a time zone has a single set of long and short names, which >>assumption is not valid if a system supports historical time zone changes. >>Actually, the time zone support in Java has this problem because it >>supports historical changes since 1.4 and always display the "latest" >>time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I >>couldn't due to another commitment. >> >>Is it possible for CLDR to make corrections to the <timeZoneNames> >>spec so that it can represent all historical name changes? >> >>Thanks, >>-- >>Masayoshi Okutsu >>Java Internationalization >>Sun Microsystems (K.K.) >> >>Mark Davis wrote: >> >> >> >> >> >>>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/formatt >>>ing/time_ >>> >>> >z > > >>> >>> >>one_localization.html >> >> >> >> >>>I'd very much appreciate any feedback on the proposal. >>> >>>Mark >>>__________________________________ >>>http://www.macchiato.com >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Friday, June 11, 2004 8:44 PM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Probably you have misunderstood my first question... Many zones have changed their time zones in their history. It's not a valid assumption that a single zone ID represents a single time zone. It may be confusing to say "zone changes time zones". Let me give you an example. Here's the history of Asia/Singapore. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - MALT 1933 Jan 1 # Malaya Time 7:00 0:20 MALST 1936 Jan 1 7:20 - MALT 1941 Sep 1 7:30 - MALT 1942 Feb 16 9:00 - JST 1945 Sep 12 7:30 - MALT 1965 Aug 9 # independence 7:30 - SGT 1982 Jan 1 # Singapore Time 8:00 - SGT During 1942-02-16 until 1945-09-12, Asia/Singapore's time zone was Japan Standard Time (GMT+09:00). (Sorry if this isn't a good example...) The LDML spec didn't look like supporting all historical time zones within a single zone. So what I'd like to see is something organized like: <zone type="Asia/Singapore" > <zoneNameSet format="SGT"> <long> <generic>Singapore Time</generic> <standard>Singapore Time</standard> <daylight>Singapore Time</daylight> </long> <short> <generic>SGT</generic> <standard>SGT</standard> <daylight>SGT</daylight> </short> </zoneNameSet> ... <zoneNameSet format="LMT"> <long> <generic>Local Mean Time</generic> ... <short> <generic>LMT</generic> ... </zoneNameSet> <exemplarCity>Singapore</exemplarCity> </zone> Obviously use of this structure involves redundant names. Probably it should have all name sets which can be referred to by <zone>. I got several bug reports on Java time zone support because it supports all historical changes since 1.4. Some customers were just confused with historically correct local time. Some of them could have been avoided if Java was capable of giving historically correct time zone names. Hope my question is now clearer. Thanks, Masayoshi Mark Davis wrote: >I don't know where you are getting that. They are *not* user-defined >IDs. The text in http://www.unicode.org/reports/tr35/ defines the IDs >as matching the IDs in ftp://elsie.nci.nih.gov/pub/. See also >http://www.unicode.org/cldr/data_formats.html#Display_Names also. > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > >----- Original Message ----- >From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)lecserver.nci.nih.gov> >Sent: Fri, 2004 Jun 11 08:41 >Subject: Re: Time Zone Localizations > > >Mark Davis wrote: > > > >>Actually, this is directly related, since LDML is the format used for CLDR. >>However, the comment is based on a misunderstanding: LDML currently >>does allow for translation of *all* of the timezone IDs, modern and historical. >> >> >> >> >I guess you don't translate timezone IDs... Anyway, do you mean that >LDML allows users to define DTD? (Sorry if this is not a correct way to >talk about XML...) So the syntax of <zone> is really user-defined? > >Thanks, >Masayoshi > > > >>The problems we are trying to address with this proposal are that the >>sheer volume of translations is difficult to manage, *and* many >>languages just don't have corresponding terms. And we didn't give >>guidance before as to which IDs were the most important to translate, >>so the translations that are in CLDR were not done in any kind of priority order. >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >>----- Original Message ----- >>From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >>To: "Mark Davis" <mark.davis(a)jtcsv.com> >>Cc: <tz(a)lecserver.nci.nih.gov> >>Sent: Fri, 2004 Jun 11 06:43 >>Subject: Re: Time Zone Localizations >> >> >>This is a bit off from the proposal, but related to time zone localizations. >> >>It appears that the Locale Data Markup Language spec for >><timeZoneNames> >>(http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes >>that a time zone has a single set of long and short names, which >>assumption is not valid if a system supports historical time zone changes. >>Actually, the time zone support in Java has this problem because it >>supports historical changes since 1.4 and always display the "latest" >>time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I >>couldn't due to another commitment. >> >>Is it possible for CLDR to make corrections to the <timeZoneNames> >>spec so that it can represent all historical name changes? >> >>Thanks, >>-- >>Masayoshi Okutsu >>Java Internationalization >>Sun Microsystems (K.K.) >> >>Mark Davis wrote: >> >> >> >> >> >>>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/formatt >>>ing/time_ >>> >>> >z > > >>> >>> >>one_localization.html >> >> >> >> >>>I'd very much appreciate any feedback on the proposal. >>> >>>Mark >>>__________________________________ >>>http://www.macchiato.com >>>► शिष्यादिच्छेत्पराजयम् ◄ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Friday, June 11, 2004 11:42 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Mark Davis wrote: >Actually, this is directly related, since LDML is the format used for CLDR. >However, the comment is based on a misunderstanding: LDML currently >does allow for translation of *all* of the timezone IDs, modern and historical. > > I guess you don't translate timezone IDs... Anyway, do you mean that LDML allows users to define DTD? (Sorry if this is not a correct way to talk about XML...) So the syntax of <zone> is really user-defined? Thanks, Masayoshi >The problems we are trying to address with this proposal are that the >sheer volume of translations is difficult to manage, *and* many >languages just don't have corresponding terms. And we didn't give >guidance before as to which IDs were the most important to translate, >so the translations that are in CLDR were not done in any kind of priority order. > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > >----- Original Message ----- >From: "Masayoshi Okutsu" <Masayoshi.Okutsu(a)Sun.COM> >To: "Mark Davis" <mark.davis(a)jtcsv.com> >Cc: <tz(a)lecserver.nci.nih.gov> >Sent: Fri, 2004 Jun 11 06:43 >Subject: Re: Time Zone Localizations > > >This is a bit off from the proposal, but related to time zone localizations. > >It appears that the Locale Data Markup Language spec for ><timeZoneNames> >(http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that >a time zone has a single set of long and short names, which assumption >is not valid if a system supports historical time zone changes. >Actually, the time zone support in Java has this problem because it >supports historical changes since 1.4 and always display the "latest" >time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I >couldn't due to another commitment. > >Is it possible for CLDR to make corrections to the <timeZoneNames> spec >so that it can represent all historical name changes? > >Thanks, >-- >Masayoshi Okutsu >Java Internationalization >Sun Microsystems (K.K.) > >Mark Davis wrote: > > > >>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/formatti >>ng/time_z >> >> >one_localization.html > > >>I'd very much appreciate any feedback on the proposal. >> >>Mark >>__________________________________ >>http://www.macchiato.com >>► शिष्यादिच्छेत्पराजयम् ◄ >> >> >> >> >> >> > > > > >

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Friday, June 11, 2004 10:50 AM To: Chuck Soper Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations Chuck Soper wrote: > Are these tables informational or vital to the process? For example, > will the Aliases table be used to "Canonicalize the Olson ID" (step 1 > of the Fallback procedure)? If so, then the table should be based on > the current time zone data files instead of "current Java data". This > could turn into a serious maintenance issue. Ideally, I think that a > script could be run on the time zone data files to generate a new > aliases table each time the time zone data files are updated > (currently tzdata2004a). I agree. And it's unclear what the "current Java data" is. *My* current Java data is tzdata2004a, which is very unlikely to be shipped with 1.5... > Where did AET (line 2, Aliases table) for Australia/Sydney come from? > I can't find any reference to it in tzdata2004a. I guess it came from JDK1.1 compatibility names. Someone (not me!) invented 3-letter time zone IDs in JDK 1.1, which failed to support more time zones. Java uses the Olson zone IDs since 1.2. But we still have the JDK 1.1 compatibility names as far as they don't conflict with any Olson zone IDs. > ### Equivalent Modern Zones > My first reaction whenever I see a significant effort to simplify > something for the user is to think that it could lead to problems. I tend to agree with you. I think we should find out another way to reduce the number of localized time zone name strings. > How did you determine that "A lot of people just don't care about > historic differences"? Do most people use time zones merely to keep > track of the current time or current differences between another time > zone? How else do users use time zones? Right. And how can we define "current" for time zones which change their offsets some time in the future, like America/Mendoza in tzdata2004a? The day after tomorrow...? :-) Masayoshi

1 0

FW: Time Zone Localizations
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Masayoshi Okutsu has been added to the time zone mailing list; this is a message sent before Masayoshi was added. --ado -----Original Message----- From: Masayoshi Okutsu [mailto:Masayoshi.Okutsu@Sun.COM] Sent: Friday, June 11, 2004 9:43 AM To: Mark Davis Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Time Zone Localizations This is a bit off from the proposal, but related to time zone localizations. It appears that the Locale Data Markup Language spec for <timeZoneNames> (http://www.unicode.org/reports/tr35/#%3CtimeZoneNames%3E) assumes that a time zone has a single set of long and short names, which assumption is not valid if a system supports historical time zone changes. Actually, the time zone support in Java has this problem because it supports historical changes since 1.4 and always display the "latest" time zone names. I planned to fix it in J2SE 1.5 (a.k.a. Tiger), but I couldn't due to another commitment. Is it possible for CLDR to make corrections to the <timeZoneNames> spec so that it can represent all historical name changes? Thanks, -- Masayoshi Okutsu Java Internationalization Sun Microsystems (K.K.) Mark Davis wrote: >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/formattin >g/time_zone_localization.html > >I'd very much appreciate any feedback on the proposal. > >Mark >__________________________________ >http://www.macchiato.com >► शिष्यादिच्छेत्पराजयम् ◄ > > > >

1 0

IERS Message No. 58: IERS Conventions Center: New discussion foru m and web site.
by IERS Central Bureau June 15, 2004

June 15, 2004

*************************************************************************** IERS Message No. 58 June 15, 2004 *************************************************************************** IERS Conventions Center: New discussion forum and web site. The IERS Conventions center has developed a Discussion Forum and a new web and ftp site for the IERS Conventions, on a server at the BIPM. 1) The user discussion forum http://tai.bipm.org/iers/forum/ is open for users to offer their comments, criticism, and suggestions regarding the update of the IERS Conventions. It is organized in themes following the present structure of the IERS Conventions (2003). To post a contribution it is necessary to be registered. Registration is a very simple procedure. It is only necessary to provide a login_name and password, and a valid e-mail address. It is recommended that the login_name be representative of your real name because the login_name is used to identify the authors of contributions. Reading the contributions is open and anonymous. A number of contributions have been posted in advance of the public opening by Jim Ray in order to stimulate discussions. Responses and new contributions are welcome. 2) The new ftp site ftp://tai.bipm.org/iers/ has two directories: * ftp://tai.bipm.org/iers/conv2003/ is a mirror of the usual ftp site ftp://maia.usno.navy.mil/conv2003/ containing all files of the Conventions (2003) (Note that as of June 4, 2004 the pdf files of the chapters have not been updated on the USNO site). * ftp://tai.bipm.org/iers/convupdt/ is used to store material relative to future updates of the IERS Conventions. 3) The new web site http://tai.bipm.org/iers/ has two main pages: * http://tai.bipm.org/iers/conv2003/conv2003.html which ultimately points to the material of the Conventions (2003). * http://tai.bipm.org/iers/convupdt/convupdt.html which is used for Conventions updates. It is planned to save all the information on successive updates incrementing in the pages of each chapter. See an example version in http://tai.bipm.org/iers/convupdt/convupdt_c5.html Gérard Petit and Dennis D. McCarthy IERS Conventions Center *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0

RE: zdump -v crashes with 64-bit time_t
by Olson, Arthur David (NIH/NCI) June 15, 2004

June 15, 2004

Here's a proposed change to zdump to avoid crashes when NULL is returned by asctime. --ado ------- zdump.c ------- *** /tmp/geta13866 Mon Jun 14 11:47:06 2004 --- /tmp/getb13866 Mon Jun 14 11:47:06 2004 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.31"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.32"; /* ** This code has been made independent of the rest of the time *************** *** 334,339 **** --- 334,346 ---- return result; } + static char * + nonnull(s) + const char * const s; + { + return (s == NULL) ? "NULL" : s; + } + static void show(zone, t, v) char * zone; *************** *** 344,352 **** (void) printf("%-*s ", (int) longest, zone); if (v) ! (void) printf("%.24s UTC = ", asctime(gmtime(&t))); tmp = localtime(&t); ! (void) printf("%.24s", asctime(tmp)); if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); if (v) { --- 351,359 ---- (void) printf("%-*s ", (int) longest, zone); if (v) ! (void) printf("%.24s UTC = ", nonnull(asctime(gmtime(&t)))); tmp = localtime(&t); ! (void) printf("%.24s", nonnull(asctime(tmp))); if (*abbr(tmp) != '\0') (void) printf(" %s", abbr(tmp)); if (v) {

3 5