- tz - lists.iana.org

FW: Incorrect timezone placement
by Olson, Arthur David (NIH/NCI) Sept. 21, 2004

Sept. 21, 2004

Arthur Pemberton is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Arthur Pemberton [mailto:pembo13@flashmail.com] Sent: Tuesday, September 21, 2004 1:53 PM To: tz(a)lecserver.nci.nih.gov Subject: Incorrect timezone placement To whom it may concern, I had raised a bug report with the folks at KDE.org here [http://bugs.kde.org/show_bug.cgi?id=89923] thinkign that they had made a mistake with the time zone for my country Dominica (DM). They suggested that I take up the matter with you, and so I am. As an inhabitant of Dominica and the Caribbean by extention, I can assure you that we are on the EST clock. I must admit my knowledge of these matters are primitive at best, however, when CNN shows the time for EST it's correct with our own, and when they show it for AST it's different from our own. Could anything be done about this? Thank you.

2 1

proposed tz changes for Uruguay, comments on Israel, etc.
by Paul Eggert Sept. 20, 2004

Sept. 20, 2004

The changes in Uruguay took effect this morning, so I guess we need to update the tz database pronto. Thanks to Eduardo Cota for the detailed information. Here is a proposed patch to deal with this, along with comments about the situation in Israel (thanks to Ephraim Silverberg) and a refresh of the tz-links page. =================================================================== RCS file: RCS/southamerica,v retrieving revision 2004.2 retrieving revision 2004.2.1.1 diff -pu -r2004.2 -r2004.2.1.1 --- southamerica 2004/07/19 18:32:49 2004.2 +++ southamerica 2004/09/20 20:13:02 2004.2.1.1 @@ -1029,6 +1029,11 @@ Rule Uruguay 1990 1992 - Mar Sun>=1 0:0 Rule Uruguay 1990 1991 - Oct Sun>=21 0:00 1:00 S Rule Uruguay 1992 only - Oct 18 0:00 1:00 S Rule Uruguay 1993 only - Feb 28 0:00 0 - +# From Eduardo Cota (2004-09-20): +# The uruguayan government has decreed a change in the local time.... +# http://www.presidencia.gub.uy/decretos/2004091502.htm +Rule Uruguay 2004 only - Sep Sun>=15 0:00 1:00 S +Rule Uruguay 2005 only - Mar Sun>=8 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 -3:44:44 - MMT 1920 May 1 # Montevideo MT =================================================================== RCS file: RCS/asia,v retrieving revision 2004.2 retrieving revision 2004.2.1.1 diff -pu -r2004.2 -r2004.2.1.1 --- asia 2004/07/19 18:32:48 2004.2 +++ asia 2004/09/20 20:13:02 2004.2.1.1 @@ -639,7 +639,7 @@ Rule Zion 1988 only - Apr 9 0:00 1:00 D Rule Zion 1988 only - Sep 3 0:00 0 S # From Ephraim Silverberg <ephraim(a)cs.huji.ac.il> -# (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17 and 2000-07-25): +# (1997-03-04, 1998-03-16, 1998-12-28, 2000-01-17, 2000-07-25, and 2004-09-20): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. @@ -735,6 +735,14 @@ Rule Zion 2003 only - Oct 3 1:00 0 S Rule Zion 2004 only - Apr 7 1:00 1:00 D Rule Zion 2004 only - Sep 22 1:00 0 S +# The latest rumour, however, is that in 2005, when the clock changes to +# Daylight Saving Time (date as yet unknown), the move will be a two-hour leap +# forward (from UTC+0200 to UTC+0400) and then, in the fall, the clock will +# move back only an hour to UTC+0300 thus effectively moving Israel's timezone +# from UTC+0200 to UTC+0300. However, no actual draft has been put before the +# Knesset (Israel's Parliament) though the intention is to do so this +# month [2004-09]. + # From Paul Eggert (2000-07-25): # Here are guesses for rules after 2004. # They are probably wrong, but they are more likely than no DST at all. =================================================================== RCS file: RCS/tz-link.htm,v retrieving revision 2004.2 retrieving revision 2004.2.1.1 diff -pu -r2004.2 -r2004.2.1.1 --- tz-link.htm 2004/07/19 18:32:49 2004.2 +++ tz-link.htm 2004/09/20 21:25:22 2004.2.1.1 @@ -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-07-13" /> +<meta name="DC.Date" content="2004-09-20" /> <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" /> @@ -23,25 +23,28 @@ </address> <p> Please send corrections to this web page to the -<a href="mailto:tz@elsie.nci.nih.gov">time zone mailing list</a>. -</p> +<a href="mailto:tz@elsie.nci.nih.gov">time zone mailing list</a>.</p> <h2>The <code>tz</code> database</h2> <p> The public-domain time zone database contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies -to UTC offsets and daylight-saving rules. +to <abbr title="Coordinated Universal Time">UTC</abbr> +offsets and daylight-saving rules. This database (often called <code>tz</code> or <code>zoneinfo</code>) is used by several implementations, including -<a href="http://www.gnu.org/software/libc/">the GNU C Library</a> used in -<a href="http://www.linux.org/">GNU/Linux</a>, +<a href="http://www.gnu.org/software/libc/">the +<acronym title="GNU's Not Unix">GNU</acronym> +C Library</a> used in +<a href="http://www.linux.org/"><acronym>GNU</acronym>/Linux</a>, <a href="http://www.freebsd.org/">FreeBSD</a>, <a href="http://www.netbsd.org/">NetBSD</a>, <a href="http://www.openbsd.org/">OpenBSD</a>, <a href="http://www.cygwin.com/">Cygwin</a>, -<a href="http://www.delorie.com/djgpp/">DJGPP</a>, +<a href="http://www.delorie.com/djgpp/"><abbr +title="DJ's GNU Programming Platform">DJGPP</abbr></a>, <a href="http://www.hp.com/products1/unix/operating/">HP-UX</a>, <a href="http://www.sgi.com/developers/technology/irix/">IRIX</a>, <a href="http://www.apple.com/macosx/">Mac OS X</a>, @@ -55,24 +58,30 @@ clocks keeping local time have agreed si Locations are identified by continent or ocean and then by the name of the location, which is typically the largest city within the region. For example, <code>America/New_York</code> -represents most of the US eastern time zone; +represents most of the <abbr title="United States">US</abbr> eastern time zone; <code>America/Indianapolis</code> represents most of Indiana, which -uses eastern time without daylight saving time (DST); +uses eastern time without daylight saving time (<abbr +title="daylight saving time">DST</abbr>); <code>America/Detroit</code> represents most of Michigan, which uses -eastern time but with different DST rules in 1975; +eastern time but with different <abbr>DST</abbr> rules in 1975; and other entries represent smaller regions like Starke County, Kentucky, which switched from central to eastern time in 1991. -To use the database, set the <code>TZ</code> environment variable to +To use the database on an extended <a +href="http://www.pasc.org/#POSIX"><abbr +title="Portable Operating System Interface">POSIX</abbr></a> +implementation set the <code>TZ</code> environment variable to the location's full name, e.g., <code>TZ="America/New_York"</code>.</p> <p> In the <code>tz</code> database's -<a href="ftp://elsie.nci.nih.gov/pub/">FTP distribution</a>, +<a href="ftp://elsie.nci.nih.gov/pub/"><abbr +title="File Transfer Protocol">FTP</abbr> distribution</a> the code is in the file <code>tzcode<var>C</var>.tar.gz</code>, where <code><var>C</var></code> is the code's version; similarly, the data are in <code>tzdata<var>D</var>.tar.gz</code>, where <code><var>D</var></code> is the data's version. The following shell commands download -these files to a GNU/Linux or similar host; see the downloaded +these files to a <acronym>GNU</acronym>/Linux or similar host; +see the downloaded <code>README</code> file for what to do next.</p> <pre style="margin-left: 2em"><code><a href="http://www.gnu.org/software/wget/">wget</a> 'ftp://elsie.nci.nih.gov/pub/tz*.tar.gz' <a href="http://www.gnu.org/software/gzip/">gzip</a> -dc tzcode*.tar.gz | <a href="http://www.gnu.org/software/tar/">tar</a> -xf - @@ -92,7 +101,10 @@ mailing list, retrieve the <a href="ftp://elsie.nci.nih.gov/pub/tzarchive.gz">archive of old messages</a> (in gzip compressed format), or retrieve <a href="ftp://munnari.oz.au/pub/oldtz/">archived older versions of code -and data</a>.</p> +and data</a>; there is also a smaller <a +href="http://public.planetmirror.com/pub/timezone/"><abbr +title="Hypertext Transfer Protocol">HTTP</abbr> +mirror</a>.</p> <p> The Web has several other sources for time zone and daylight saving time data. Here are some recent links that may be of interest. @@ -104,7 +116,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.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP">Current Time in 1000 Places</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.timeanddate.com/worldclock/">The World Clock - @@ -116,21 +130,29 @@ is a web interface to a time zone databa <ul> <li>The <a href="ftp://ftp.rfc-editor.org/in-notes/rfc2445.txt"> Internet Calendaring and Scheduling Core Object Specification -(iCalendar)</a> specification published by the <a -href="http://www.ietf.org/html.charters/calsch-charter.html">IETF -Calendaring and Scheduling Working Group (calsch)</a> covers time zone +(iCalendar)</a> specification published by the (now-concluded) <a +href="http://www.ietf.org/html.charters/OLD/calsch-charter.html"><abbr +title="Internet Engineering Task Force">IETF</abbr> +Calendaring and Scheduling Working Group (<abbr +title="Calendaring and Scheduling Working Group">calsch</abbr>)</a> +covers time zone data; see its VTIMEZONE calendar component.</li> <li>The <a href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a> -list discusses <a href="http://www.w3.org/RDF/">RDF</a>-based calendar +list discusses <a +href="http://www.w3.org/RDF/"><abbr +title="Resource Description Framework">RDF</abbr></a>-based calendar and group scheduling systems, and has a <a href="http://www.w3.org/2002/12/cal/#tzd">workspace on time zone data</a> converted from <code>tz</code>. An earlier <a href="http://www.w3.org/2000/01/foo">schema</a> was sketched out by <a href="http://www.w3.org/People/Berners-Lee/">Tim Berners-Lee</a>.</li> <li><a -href="http://www.calsch.org/ietf/archives/draft-ietf-calsch-many-xcal-02.txt">XCal</a> -was a draft <a href="http://www.w3.org/XML/">XML</a> document type +href="http://www.calsch.org/ietf/archives/draft-ietf-calsch-many-xcal-02.txt"><abbr +title="XML DTD for iCalendar">XCal</abbr></a> +was a draft <a +href="http://www.w3.org/XML/"><abbr +title="Extensible Markup Language">XML</abbr></a> document type definition that corresponded to iCalendar.</li> </ul> <h2>Other <code>tz</code> compilers</h2> @@ -139,47 +161,55 @@ definition that corresponded to iCalenda Timezone Converter</a> describes a program Vzic that compiles <code>tz</code> source into iCalendar-compatible VTIMEZONE files. Vzic is freely -available under the <a href="http://www.gnu.org/copyleft/gpl.html">GNU -General Public License (GPL)</a>.</li> +available under the <a +href="http://www.gnu.org/copyleft/gpl.html"><acronym>GNU</acronym> +General Public License (<abbr +title="General Public License">GPL</abbr>)</a>.</li> <li><a href="http://search.cpan.org/dist/DateTime-TimeZone/">DateTime::TimeZone</a> contains a script <code>parse_olson</code> that compiles <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 Artistic +available under both the <abbr>GPL</abbr> 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 -Unicode (ICU)</a> contains a C/C++ library for internationalization that -has a compiler from <samp>tz</samp> source into an ICU-specific format. -ICU is freely available under a BSD-style license.</li> +<li><a href="http://oss.software.ibm.com/icu/"><abbr +title="International Components for Unicode">ICU</abbr></a> contains a C/C++ library for +internationalization that has a compiler from <samp>tz</samp> source +into an <abbr>ICU</abbr>-specific format. +<abbr>ICU</abbr> is freely available under a +<abbr title="Berkeley Software Distribution">BSD</abbr>-style license.</li> <li><a href="http://joda-time.sourceforge.net/">Joda Time - Java date -and time API</a> contains a class +and time <abbr title="Application Program Interface">API</abbr></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> +is freely available under a <abbr>BSD</abbr>-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> +It is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> <h2>Other <code>tz</code> binary file readers</h2> <ul> -<li>The <a href="http://www.gnu.org/software/libc/">GNU C Library</a> +<li>The <a +href="http://www.gnu.org/software/libc/"><acronym>GNU</acronym> C +Library</a> has an independent, thread-safe implementation of a <code>tz</code> binary file reader. This library is freely available under the <a href="http://www.gnu.org/copyleft/lesser.html"> -GNU Lesser General Public License (LGPL)</a>, -and is widely used in GNU/Linux systems.</li> +<acronym>GNU</acronym> Lesser General Public License +(<abbr title="Lesser General Public License">LGPL</abbr>)</a>, +and is widely used in <acronym>GNU</acronym>/Linux systems.</li> <li><a href="http://www.bmsi.com/java/#TZ">ZoneInfo.java</a> is a <code>tz</code> binary file reader written in Java. -It is freely available under the GNU LGPL.</li> +It is freely available under the <acronym>GNU</acronym> +<abbr>LGPL</abbr>.</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 Python. -It is freely available under a BSD-style license.</li> +It is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> <h2>Other <code>tz</code>-based time zone conversion software</h2> <ul> @@ -198,8 +228,8 @@ Microsoft Windows program.</li> <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 +href="http://astrocom.com/products/software.php?software_id=ibmwboth">computer +and book form</a> by <a href="http://astrocom.com/">Astro Communications Services</a>.</li> <li><a href="http://worldtime.com/">WORLDTIME: interactive atlas, time info, public holidays</a> @@ -208,14 +238,14 @@ and public holidays in several hundred c <li><a href="http://www.worldtimeserver.com/">World Time Server</a> is another time zone database.</li> <li><a href="http://tycho.usno.navy.mil/tzones.html">World Time Zones</a> -contains data from the Time Service Department of the US Naval Observatory -(USNO), used as the source +contains data from the Time Service Department of the +<abbr>US</abbr> Naval Observatory, used as the source for the <code>usno*</code> files in the <code>tz</code> distribution.</li> <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/ps/publications/9179.htm">Standard -Schedules Information Manual (SSIM)</a> of the +Schedules Information Manual</a> of the the <a href="http://www.iata.org/">International Air Transport Association</a>, which gives current time zone rules for @@ -224,7 +254,8 @@ all the airports served by commercial av <h2>Maps</h2> <ul> <li>The <a href="http://www.odci.gov/">United States Central -Intelligence Agency (CIA)</a> publishes a <a +Intelligence Agency (<abbr +title="Central Intelligence Agency">CIA</abbr>)</a> publishes a <a href="http://www.odci.gov/cia/publications/factbook/reference_maps/pdf/time_zones…">time zone map</a>; the <a @@ -238,19 +269,26 @@ and parts of the data are a few years ou <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 +The maps' pictorial quality is not quite as good as the +<abbr>CIA</abbr>'s but the maps are more up to date.</li> </ul> <h2>Time zone boundaries</h2> <ul> +<li><a href="http://www.statoids.com/statoids.html">Administrative Divisions +of Countries ("Statoids")</a> contains detailed lists of +<code>tz</code>-related zone subdivision data.</li> <li><a href="http://home-4.tiscali.nl/~t876506/Multizones.html">Time zone boundaries for multizone countries</a> summarizes legal boundaries between time zones within countries.</li> <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.</li> -<li>The US Geological Survey's National Atlas of the United States +<acronym title="Geographic Information Systems">GIS</acronym> +Data</a> includes a Manifold-format map of +world time zone boundaries distributed under the +<abbr>GPL</abbr>.</li> +<li>The <abbr>US</abbr> 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> <li>The GeoCommunity lists several commercial sources for <a @@ -262,8 +300,8 @@ Time Zones and Time Zone Data</a>.</li> <li><a href="http://physics.nist.gov/time">A Walk through Time</a> surveys the evolution of timekeeping.</li> <li><a href="http://webexhibits.org/daylightsaving/">About Daylight -Saving Time - History, rationale, laws and dates</a> -is an overall history of DST.</li> +Saving Time - History, rationale, laws & dates</a> +is an overall history of <abbr>DST</abbr>.</li> <li><a href="http://toi.iriti.cnr.it/">The Time of Internet</a> describes time zones and daylight saving time, @@ -278,10 +316,11 @@ Zone Concepts</a> discusses terminologic <h2>National histories of legal time</h2> <dl> <dt>Australia</dt> -<dd>The Community Relations Division of the New South Wales (NSW) +<dd>The Community Relations Division of the New South Wales +(<abbr title="New South Wales">NSW</abbr>) Attorney General's Department maintains a <a href="http://www.lawlink.nsw.gov.au/crd.nsf/pages/time2">history of -daylight saving in NSW</a>.</dd> +daylight saving in <abbr>NSW</abbr></a>.</dd> <dt>Austria</dt> <dd>The Federal Office of Metrology and Surveying publishes a table of <a href="http://www.metrologie.at/pdf/sommerzeit.pdf" @@ -350,40 +389,59 @@ of summer time dates</a>.</dd> href="http://literature.agilent.com/litwebbin/purl.cgi?org_id=tmo&pub_id=5965…">The Science of Timekeeping</a> is a thorough introduction to the theory and practice of precision timekeeping.</li> -<li><a href="http://www.ntp.org/">NTP: The Network Time Protocol</a> +<li><a href="http://www.ntp.org/"><abbr +title="Network Time Protocol">NTP</abbr>: The Network +Time Protocol</a> discusses how to synchronize clocks of Internet hosts.</li> -<li><a href="http://gauss.gge.unb.ca/GMT.UT.and.the.RGO.txt" -charset="macintosh">A -Few Facts Concerning GMT, UT, and the RGO</a> -answers questions like "What is the difference between GMT and UTC?"</li> +<li><a href="http://gauss.gge.unb.ca/GMT.UT.and.the.RGO.html">A Few +Facts Concerning <abbr title="Greenwich Mean Time">GMT</abbr>, <abbr +title="Universal Time">UT</abbr>, and +the <abbr title="Royal Greenwich Observatory">RGO</abbr></a> +answers questions like "What is the +difference between <abbr>GMT</abbr> and <abbr>UTC</abbr>?"</li> <li><a href="http://www.gb.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical -Times</a> explains more abstruse astronomical time scales like TT, TCG, -and TDB.</li> -<li>The <a href="http://www.iau.org/">IAU</a>'s <a -href="http://www.iau-sofa.rl.ac.uk/">Standards Of Fundamental -Astronomy</a> (SOFA) initiative publishes Fortran code for converting -among time scales like TAI, TDB, TT and UTC.</li> +Times</a> explains more abstruse astronomical time scales like +<abbr title="Terrestrial Dynamic Time">TDT</abbr>, +<abbr title="Geocentric Coordinate Time">TCG</abbr>, and +<abbr title="Barycentric Dynamic Time">TDB</abbr>.</li> +<li>The <a href="http://www.iau.org/"><abbr +title="International Astronomical Union">IAU</abbr></a>'s <a +href="http://www.iau-sofa.rl.ac.uk/"><acronym +title="Standards Of Fundamental Astronomy">SOFA</acronym></a> +initiative publishes Fortran +code for converting among time scales like +<abbr title="International Atomic Time">TAI</abbr>, +<abbr>TDB</abbr>, <abbr>TDT</abbr> and +<abbr>UTC</abbr>.</li> <li><a href="http://www.jpl.nasa.gov/basics/bsf2-3.htm">Basics of Space Flight - Reference Systems - Time Conventions</a> briefly explains interplanetary space flight timekeeping.</li> <li><a href="http://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a> briefly -describes Mars Coordinated Time (MTC) and the diverse local time +describes Mars Coordinated Time (<abbr +title="Mars Coordinated Time">MTC</abbr>) and the +diverse local time scales used by each landed mission on Mars.</li> <li><a href="http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html">Bulletins -maintained by the IERS EOP (PC)</a> contains official publications of +maintained by the +<abbr title="International Earth Rotation Service">IERS</abbr> +<abbr title="Earth Orientation Parameters">EOP</abbr> +(<abbr title="Product Center">PC</abbr>)</a> contains official publications of the Earth Orientation Parameters Product Center of the International Earth Rotation Service, the committee that decides when leap seconds occur.</li> <li>The <a href="http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/">Leap -Second Discussion List</a> covers McCarthy and Klepczynski's proposal -to discontinue leap seconds, published in <a -href="http://www.gpsworld.com/">GPS World</a> <strong>10</strong>, 11 +Second Discussion List</a> covers <a +href="http://gauss.gge.unb.ca/papers.pdf/gpsworld.november99.pdf">McCarthy +and Klepczynski's proposal to discontinue leap seconds</a>, published in <a +href="http://www.gpsworld.com/"><abbr +title="Global Positioning System">GPS</abbr> World</a> +<strong>10</strong>, 11 (1999-11), 50–57 and discussed further in R. A. Nelson et al., <a href="http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf">The leap second: its history and possible future</a>, @@ -398,47 +456,46 @@ contentious issue.</li> <li> <a href="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">A Summary of the International Standard Date and Time Notation</a> is a good -summary of ISO +summary of <abbr title="International Organization for Standardization">ISO</abbr> 8601:1988 - Data elements and interchange formats - Information interchange - Representation of dates and times (which has been superseded by -<a href="http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780">ISO 8601:2000</a>).</li> -<li> -Section 3.3 of <a -href="ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt">Internet RFC 2822</a> -specifies the time notation used in email and <a -href="ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt">HTTP</a> headers.</li> -<li> -<a href="ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt">Internet RFC -3339</a> specifies an ISO 8601 profile for use in new Internet -protocols.</li> -<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 +<a +href="http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780"><abbr>ISO</abbr> +8601:2000</a>).</li> <li> Section 3.3 of <a +href="ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt">Internet +<abbr title="Request For Comments">RFC</abbr> 2822</a> +specifies the time notation used in +email and <a +href="ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt"><abbr>HTTP</abbr></a> +headers.</li> <li> <a +href="ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt">Internet +<abbr>RFC</abbr> 3339</a> specifies an <abbr>ISO</abbr> 8601 +profile for use in new Internet protocols.</li> <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 -example, "EST" denotes 5 hours behind UTC in English-speaking North -America, but it denotes 10 or 11 hours ahead of UTC in Australia; -and French-speaking North Americans prefer "HNE" to "EST". For -compatibility with <a href="http://www.pasc.org/#POSIX">POSIX</a> the -<code>tz</code> database contains English abbreviations for all time -stamps but in many cases these are merely inventions of the database -maintainers.</li> -</ul> -<h2>Related indexes</h2> -<ul> -<li><a href="tz-art.htm">Time and the Arts</a></li> -<li><a href="http://dmoz.org/Reference/Time/">Open Directory - -Reference: Time</a></li> -<li><a href="http://directory.google.com/Top/Reference/Time/">Google Directory - Reference > Time</a></li> -<li><a href="http://dir.yahoo.com/Science/Measurements_and_Units/Time/">Yahoo! Science > Measurements and Units > Time</a></li> -</ul> -</body> +Russian translations for "Eastern European Summer Time", +"<abbr title="Eastern European Summer Time">EEST</abbr>", +and <code>Europe/Bucharest</code>.</li> +<li> Alphabetic time zone abbreviations should not be used as unique +identifiers for <abbr>UTC</abbr> offsets as they are ambiguous in +practice. For example, "<abbr>EST</abbr>" denotes 5 hours behind +<abbr>UTC</abbr> in English-speaking North America, but it denotes 10 +or 11 hours ahead of <abbr>UTC</abbr> in Australia; and +French-speaking North Americans prefer +"<abbr title="Heure Normale de l'Est">HNE</abbr>" to +"<abbr>EST</abbr>". For <abbr>POSIX</abbr> the <code>tz</code> +database contains English abbreviations for all time stamps but in +many cases these are merely inventions of the database +maintainers.</li> </ul> <h2>Related indexes</h2> <ul> <li><a +href="tz-art.htm">Time and the Arts</a></li> <li><a +href="http://dmoz.org/Reference/Time/">Open Directory - Reference: +Time</a></li> <li><a +href="http://directory.google.com/Top/Reference/Time/">Google +Directory - Reference > Time</a></li> <li><a +href="http://dir.yahoo.com/Science/Measurements_and_Units/Time/">Yahoo! +Science > Measurements and Units > Time</a></li> </ul> </body> </html>

1 0

FW: URUGUAY: zoneinfo modification
by Olson, Arthur David (NIH/NCI) Sept. 20, 2004

Sept. 20, 2004

Luis Pablo Perez is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Luis Pablo Perez [mailto:lpperez@adinet.com.uy] Sent: Monday, September 20, 2004 1:12 PM To: tz(a)lecserver.nci.nih.gov Subject: URUGUAY: zoneinfo modification Hello, This two rules must be included in your definitions for America/Montevideo: Rule Uruguay 2004 only - Sep 19 0:00 1:00 S Rule Uruguay 2005 only - Mar 13 0:00 0 - From Sep 19 2004 to Mar 13 2005, Uruguay will be adding one hour and changing to GMT-2. Regards Pablo

1 0

FW: Change in Uruguay time zone
by Olson, Arthur David (NIH/NCI) Sept. 20, 2004

Sept. 20, 2004

Eduardo Cota is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Eduardo [mailto:ec-acd@dedicado.net.uy] Sent: Friday, September 17, 2004 5:09 PM To: tz(a)lecserver.nci.nih.gov Subject: Change in Uruguay time zone Hello, I am writing to this address, as directed in http://www.twinsun.com/tz/tz-link.htm The uruguayan government has decreed a change in the local time. The decree in the government's web site (in Spanish): http://www.presidencia.gub.uy/decretos/2004091502.htm This means that from 19/9/2004 (at 0:00 local time) until 13/3/2004 (at 0:00 local time) official time in Uruguay will be at GMT -2 This means that the file "zoneinfo/southamerica" should be changed. I assume the change must be to add the following 2 lines (warning: this is the first time I have touched a time zone file): Rule Uruguay 2004 only - Sep 19 0:00 1:00 S Rule Uruguay 2005 only - Mar 13 0:00 0 - I am no authority in Uruguay, just a timezone user. Yours, Eduardo Cota.

1 0

URUGUAY: zoneinfo modification
by Luis Pablo Perez Sept. 20, 2004

Sept. 20, 2004

Hello, This two rules must be included in your definitions for America/Montevideo: Rule Uruguay 2004 only - Sep 19 0:00 1:00 S Rule Uruguay 2005 only - Mar 13 0:00 0 - From Sep 19 2004 to Mar 13 2005, Uruguay will be adding one hour and changing to GMT-2. Regards Pablo

1 0

Change in Uruguay time zone
by Eduardo Sept. 17, 2004

Sept. 17, 2004

Hello, I am writing to this address, as directed in http://www.twinsun.com/tz/tz-link.htm The uruguayan government has decreed a change in the local time. The decree in the government's web site (in Spanish): http://www.presidencia.gub.uy/decretos/2004091502.htm This means that from 19/9/2004 (at 0:00 local time) until 13/3/2004 (at 0:00 local time) official time in Uruguay will be at GMT -2 This means that the file "zoneinfo/southamerica" should be changed. I assume the change must be to add the following 2 lines (warning: this is the first time I have touched a time zone file): Rule Uruguay 2004 only - Sep 19 0:00 1:00 S Rule Uruguay 2005 only - Mar 13 0:00 0 - I am no authority in Uruguay, just a timezone user. Yours, Eduardo Cota.

1 0

Tzcode2004d.tar.gz
by Olson, Arthur David (NIH/NCI) Sept. 13, 2004

Sept. 13, 2004

The file... ftp://elsie.nci.nih.gov/pub/tzcode2004d.tar.gz ...is now available; this includes the changes circulated last week that avoid overflow problems when TM_YEAR_BASE is added to an integer. Since there are no data changes, there's no new tzdata file. Note that strftime will be revisited to deal with two-digit-output formats. --ado

1 0

Localization Facilitation
by Chuck Soper Sept. 10, 2004

Sept. 10, 2004

Over a month ago Mark Davis posted an email that mentioned issues related to translations of time zone IDs provided by the common locale data repository project (CLDR). I'm interested to find about the status of this localization and to find a way to keep informed of the progress. The initial email discussion was somewhat lengthy and I'm sure that I did not digest all the points mentioned. The beginning of the CLDR proposal explains the current mechanism for localizing Olson Time Zone Identifiers (Olson TZIDs). And in the tz code directory, the rules for naming Olson TZIDs are in the Theory file. Many Olson TZIDs simply do not localize well. I believe that the Olson TZIDs were not designed with localization in mind. I suggest a zoneMeta.tab file (very similar to zone.tab) be created for the propose of facilitating localization. Such a file could include the following columns: - ISO 3166-1 - latitude/longitude (from zone.tab) - Olson TZID - city or place name - sub-division (i.e. state, province, prefecture, or kingdom) - time zone name, general (e.g. Eastern Time) - time zone name, specific if is exists (e.g. Eastern Standard Time - Indiana - most locations) - time zone name, std (e.g. Eastern Standard Time) - time zone name, dst (e.g. Eastern Daylight Saving Time) - historic (yes/no) - attributes (major, minor, etc.) Is Center, North Dakota minor? (perhaps historical and attributes could be combined?) - geographical comments (entire country or ISO subdivision codes?) - revision notes (always the last column) additionally there could be columns to track if a particular time zone is within another time zone. - tz level (e.g. Denver == 0, Arizona == 1) - parent Olson TZID (e.g. Arizona's parent is Denver) *** It's important that this information is maintained in the time zone database. The maintainers of the database should be the ones to determine or declare if a particular time zone is modern, historical, major, minor, or has other attributes. I also think that a meta data file for time zone abbreviations would be useful. Many abbreviations are important and widely used while others are invented by the maintainers for convenience. Currently, time zone abbreviations are not unique (e.g. EST) and need to be associated with both an ISO 3166-1 code and an Olson TZID. A abbrMeta.tab file could contain the following columns: - ISO 3166-1 - OlsonTZID - time zone abbr - regular (e.g. PT for Pacific Time) - time zone abbr - std (e.g. PST for Pacific Standard Time) - time zone abbr - dst (e.g. PDT for Pacific Daylight Saving Time) - time zone name - regular (e.g. Pacific Time for PT) - time zone name - std (e.g. Pacific Standard Time for PST) - time zone name - dst (e.g. Pacific Daylight Saving Time for PDT) - historic (yes/no) - abbr valid or in use (yes/no) - comments - revision notes A unique time zone abbreviation ID could could eliminate the need to have time zone names in both the abbrMeta.tab and zoneMeta.tab files. The zoneMeta.tab file could contain unique time zone abbreviation IDs that refer to the abbrMeta.tab file. Perhaps, simply appending the abbreviation to the ISO 3166-1 code. Pacific Standard Time for the US could be US_PDT. The purpose of these meta data files would be to provide English readable time zone information (more comprehensive than zone.tab) and to facilitate localization. These files could be added to the data directory and clearly noted that they are a work in progress. If this or a similar approach is taken the validity of these data will evolve over time. Questions: - Should the tz database attempt to maintain or track ISO 3166-1 codes that are either obsolete or do not have an associated time zone? - Should XML or XLIFF be considered for meta data only? This would allow future support for local city, sub-division, and time zone names utilizing Unicode. A local name would be in the country's own language (and there might be secondary local names for countries with more than one language). I expect to be very busy for the next couple of weeks, but I'm interested to find out if my comments are useful. Chuck

2 4

strftime %y and negative years
by Paul Eggert Sept. 10, 2004

Sept. 10, 2004

"Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > ...the suggested change to strftime is trying to get %y to > produce the "year within the century" as output. Yes, that's correct: it's trying to produce the year modulo 100. > But the latest IEEE Std 1003.1 calls for... > > %y Replaced by the last two digits of the year as a decimal > number [00,99]. Read literally, this would have undefined behavior for the years -9 through 9 (since they don't have two digits), and would generate "10" for the year -10, and so forth, which obviously disagrees with the proposed "year modulo 100" semantics. However, I just checked 3 implementations and found that nobody obeys the literal behavior for years before -9, that there's disagreement about negative single-digit years, and that at least one traditional Unix implementation mishandles years before 1900 (not too surprising, since the Unix Version 7 ctime allowed only years in the range 1900..2099). Here's what I found. year (i.e., glibc 2.2.5 OpenBSD 3.4 Solaris 9 tm_year-1900) (Debian patch 112874-29 2.2.5-11.5) (64-bit sparc) -101 99 -1 0/ -100 00 00 00 -99 01 -99 '' (i.e., two apostrophes) ... -2 98 -2 0. -1 99 -1 0/ 0 00 00 00 1 01 01 '' ... 9 09 09 '/ 10 10 10 '0 11 11 11 (' ... 99 99 99 0/ 100 00 00 00 101 01 01 '' ... 1899 99 99 0/ 1900 00 00 00 ... The implementations agreed for years after 1899, until they got to the year 2**31: 2**31 - 1 47 47 47 2**31 48 -48 48 2**31 + 1 49 -47 49 2**31 + 2 50 -46 50 .... 2**31 + 1897 45 -51 45 2**31 + 1898 46 -50 46 2**31 + 1899 47 -49 47 So it appears that, in practice, the behavior of strftime %y is undefined when tm_year is negative, or when tm_year+1900 exceeds INT_MAX. I don't know whether the standards committee would consider all this to be a bug in the standard or in the implementations, but here's what I think. The Solaris behavior is clearly buggy for years before 1900. The OpenBSD behavior is clearly buggy for years after 2**31 - 1. For years before 0, I suppose that it's debatable between OpenBSD 3.4 and glibc 2.2.5. However, I'd say that the glibc 2.2.5 behavior is cleaner, since it's more regular, it always outputs two bytes, and it doesn't output "-". PS. Disclaimer: I wrote that part of glibc 2.2.5 so my opinion is hardly impartial. PPS. Ironic, isn't it? The consensus is that new code shouldn't use ctime, as it's obsolete and is undefined for years out of the traditional range, and that new code should use strftime. But in practice, strftime has problems too. PPPS. I'll CC: this to the tz mailing list to see if anybody else has experiences with other implementations in this area, or strong opinions on the subject.

3 4

RE: Proposed strftime.c changes for long years
by Olson, Arthur David (NIH/NCI) Sept. 9, 2004

Sept. 9, 2004

Based on Paul Eggert's feedback, below find an updated set of changes to avoid problems with overflow when TM_YEAR_BASE is added to tm_year. I eliminated the tm_year #define that was designed to catch coding problems; I moved the asctime_r define to private.h (and it is now conditionalized); I changed strftime's handling of the 'C' format to use _conv rather than _lconv; and I added a note to strftime about the need to figure out what to do when a format asks for the last two digits of a year (or the century of a year) and the year is negative (or less than 100). --ado ------- private.h ------- *** /tmp/geta29972 Thu Sep 9 11:48:56 2004 --- /tmp/getb29972 Thu Sep 9 11:48:56 2004 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.53"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 7.54"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 190,200 **** --- 190,211 ---- ** But some newer errno.h implementations define it as a macro. ** Fix the former without affecting the latter. */ + #ifndef errno extern int errno; #endif /* !defined errno */ /* + ** Some time.h implementations don't declare asctime_r. + ** Others might define it as a macro. + ** Fix the former without affecting the latter. + */ + + #ifndef asctime_r + extern char * asctime_r(); + #endif + + /* ** Private function declarations. */ char * icalloc P((int nelem, int elsize)); ------- localtime.c ------- *** /tmp/geta29991 Thu Sep 9 11:48:56 2004 --- /tmp/getb29991 Thu Sep 9 11:48:56 2004 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.78"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.80"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 134,139 **** --- 134,142 ---- 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 long_normalize_overflow P((long * tensptr, + int * unitsptr, int base)); static int normalize_overflow P((int * tensptr, int * unitsptr, int base)); static void settzname P((void)); *************** *** 1149,1155 **** register const struct lsinfo * lp; register long days; register long rem; ! register int y; register int yleap; register const int * ip; register long corr; --- 1152,1158 ---- register const struct lsinfo * lp; register long days; register long rem; ! register long y; register int yleap; register const int * ip; register long corr; *************** *** 1218,1224 **** 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; newy = y + days / DAYSPERNYEAR; if (days < 0) --- 1221,1227 ---- 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 long newy; newy = y + days / DAYSPERNYEAR; if (days < 0) *************** *** 1294,1299 **** --- 1297,1314 ---- } 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,1314 **** --- 1324,1344 ---- } 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; *************** *** 1335,1342 **** register const struct state * sp; register int dir; register int bits; ! register int i, j ; register int saved_seconds; time_t newt; time_t t; struct tm yourtm, mytm; --- 1365,1374 ---- register const struct state * sp; register int dir; register int bits; ! register int i, j; register int saved_seconds; + register long li; + long y; time_t newt; time_t t; struct tm yourtm, mytm; *************** *** 1352,1393 **** return WRONG; if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; ! if (normalize_overflow(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* ! ** Turn yourtm.tm_year 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)) return WRONG; while (yourtm.tm_mday <= 0) { ! if (increment_overflow(&yourtm.tm_year, -1)) return WRONG; ! i = yourtm.tm_year + (1 < yourtm.tm_mon); ! yourtm.tm_mday += year_lengths[isleap(i)]; } 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)) return WRONG; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year)][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)) return WRONG; } } ! if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) saved_seconds = 0; ! else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. --- 1384,1429 ---- return WRONG; if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; ! y = yourtm.tm_year; ! if (long_normalize_overflow(&y, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* ! ** Turn y into an actual year number for now. ** It is converted back to an offset from TM_YEAR_BASE later. */ ! if (long_increment_overflow(&y, TM_YEAR_BASE)) return WRONG; while (yourtm.tm_mday <= 0) { ! if (long_increment_overflow(&y, -1)) return WRONG; ! li = y + (1 < yourtm.tm_mon); ! yourtm.tm_mday += year_lengths[isleap(li)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! 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(y)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; yourtm.tm_mday -= i; if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! if (long_increment_overflow(&y, 1)) return WRONG; } } ! 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 (y + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. ------- strftime.c ------- *** /tmp/geta13 Thu Sep 9 11:48:56 2004 --- /tmp/getb13 Thu Sep 9 11:48:56 2004 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.64"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". --- 1,12 ---- + /* + ** XXX To do: figure out correct (as distinct from standard-mandated) + ** output for "two digits of year" and "century" formats when + ** the year is negative or less than 100. --ado, 2004-09-09 + */ + #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.67"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 108,113 **** --- 114,120 ---- 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,216 **** ** something completely different. ** (ado, 1993-05-24) */ ! pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, "%02d", pt, ptlim); continue; case 'c': --- 217,224 ---- ** something completely different. ** (ado, 1993-05-24) */ ! pt = _conv((int) ((t->tm_year + ! (long) TM_YEAR_BASE) / 100), "%02d", pt, ptlim); continue; case 'c': *************** *** 379,390 **** ** (ado, 1996-01-02) */ { ! int year; int yday; int wday; int w; ! year = t->tm_year + TM_YEAR_BASE; yday = t->tm_yday; wday = t->tm_wday; for ( ; ; ) { --- 387,399 ---- ** (ado, 1996-01-02) */ { ! long year; int yday; int wday; int w; ! year = t->tm_year; ! year += TM_YEAR_BASE; yday = t->tm_yday; wday = t->tm_wday; for ( ; ; ) { *************** *** 426,436 **** DAYSPERNYEAR; } #ifdef XPG4_1994_04_09 ! if ((w == 52 ! && t->tm_mon == TM_JANUARY) ! || (w == 1 ! && t->tm_mon == TM_DECEMBER)) ! w = 53; #endif /* defined XPG4_1994_04_09 */ if (*format == 'V') pt = _conv(w, "%02d", --- 435,445 ---- DAYSPERNYEAR; } #ifdef XPG4_1994_04_09 ! if ((w == 52 && ! t->tm_mon == TM_JANUARY) || ! (w == 1 && ! t->tm_mon == TM_DECEMBER)) ! w = 53; #endif /* defined XPG4_1994_04_09 */ if (*format == 'V') pt = _conv(w, "%02d", *************** *** 437,446 **** pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(year % 100, "%02d", pt, ptlim); - } else pt = _conv(year, "%04d", - pt, ptlim); } continue; case 'v': --- 446,455 ---- pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(int(year % 100), ! "%02d", pt, ptlim); ! } else pt = _lconv(year, "%04ld", pt, ptlim); } continue; case 'v': *************** *** 477,488 **** continue; case 'y': *warnp = IN_ALL; ! pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, "%02d", pt, ptlim); continue; case 'Y': ! pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! pt, ptlim); continue; case 'Z': #ifdef TM_ZONE --- 486,498 ---- continue; case 'y': *warnp = IN_ALL; ! pt = _conv((int) ((t->tm_year + ! (long) TM_YEAR_BASE) % 100), "%02d", pt, ptlim); continue; case 'Y': ! pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, ! "%04ld", pt, ptlim); continue; case 'Z': #ifdef TM_ZONE *************** *** 582,587 **** --- 592,610 ---- char buf[INT_STRLEN_MAXIMUM(int) + 1]; (void) sprintf(buf, format, n); + return _add(buf, pt, 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); }

3 2

Proposed strftime.c and localtime.c changes for long years
by Olson, Arthur David (NIH/NCI) Sept. 7, 2004

Sept. 7, 2004

Attached are changes (based on those circulated on the list earlier by Paul Eggert) to strftime.c and localtime.c; these changes allow for the possibility that adding an int year to TM_YEAR_BASE might overflow an int, so the relevant math is done with longs. There are also a couple of cosmetic changes. Note that no changes to the way strftime handles two-digit year output requests are being (deliberately) made at this point. I hope to update the ftp bundle to incorporate these changes in about a week; I'd welcome any feedback before then. --ado ------- localtime.c ------- *** /tmp/geta17327 Tue Sep 7 08:12:24 2004 --- /tmp/getb17327 Tue Sep 7 08:12:24 2004 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.78"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.79"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 134,139 **** --- 134,142 ---- 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 long_normalize_overflow P((long * tensptr, + int * unitsptr, int base)); static int normalize_overflow P((int * tensptr, int * unitsptr, int base)); static void settzname P((void)); *************** *** 1149,1155 **** register const struct lsinfo * lp; register long days; register long rem; ! register int y; register int yleap; register const int * ip; register long corr; --- 1152,1158 ---- register const struct lsinfo * lp; register long days; register long rem; ! register long y; register int yleap; register const int * ip; register long corr; *************** *** 1218,1224 **** 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; newy = y + days / DAYSPERNYEAR; if (days < 0) --- 1221,1227 ---- 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 long newy; newy = y + days / DAYSPERNYEAR; if (days < 0) *************** *** 1259,1264 **** --- 1262,1268 ---- char * buf; { struct tm tm; + extern char * asctime_r(); return asctime_r(localtime_r(timep, &tm), buf); } *************** *** 1294,1299 **** --- 1298,1315 ---- } 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,1314 **** --- 1325,1345 ---- } 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; *************** *** 1335,1342 **** register const struct state * sp; register int dir; register int bits; ! register int i, j ; register int saved_seconds; time_t newt; time_t t; struct tm yourtm, mytm; --- 1366,1375 ---- register const struct state * sp; register int dir; register int bits; ! register int i, j; register int saved_seconds; + register long li; + long y; time_t newt; time_t t; struct tm yourtm, mytm; *************** *** 1352,1393 **** return WRONG; if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; ! if (normalize_overflow(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* ! ** Turn yourtm.tm_year 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)) return WRONG; while (yourtm.tm_mday <= 0) { ! if (increment_overflow(&yourtm.tm_year, -1)) return WRONG; ! i = yourtm.tm_year + (1 < yourtm.tm_mon); ! yourtm.tm_mday += year_lengths[isleap(i)]; } 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)) return WRONG; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year)][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)) return WRONG; } } ! if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) saved_seconds = 0; ! else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. --- 1385,1438 ---- return WRONG; if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; ! y = yourtm.tm_year; ! /* ! ** Hands off tm_year for a while. ! */ ! #define tm_year USE_Y_NOT_YOURTM_TM_YEAR ! if (long_normalize_overflow(&y, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* ! ** Turn y into an actual year number for now. ** It is converted back to an offset from TM_YEAR_BASE later. */ ! if (long_increment_overflow(&y, TM_YEAR_BASE)) return WRONG; while (yourtm.tm_mday <= 0) { ! if (long_increment_overflow(&y, -1)) return WRONG; ! li = y + (1 < yourtm.tm_mon); ! yourtm.tm_mday += year_lengths[isleap(li)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! 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(y)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; yourtm.tm_mday -= i; if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! if (long_increment_overflow(&y, 1)) return WRONG; } } ! if (long_increment_overflow(&y, -TM_YEAR_BASE)) return WRONG; + /* + ** Hands back on tm_year. + */ + #undef tm_year + 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 (y + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. ------- strftime.c ------- *** /tmp/geta17306 Tue Sep 7 08:12:07 2004 --- /tmp/getb17306 Tue Sep 7 08:12:07 2004 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.64"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.66"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 108,113 **** --- 108,114 ---- 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,217 **** ** something completely different. ** (ado, 1993-05-24) */ ! pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, ! "%02d", pt, ptlim); continue; case 'c': { --- 211,219 ---- ** something completely different. ** (ado, 1993-05-24) */ ! pt = _lconv((t->tm_year + ! (long) TM_YEAR_BASE) / 100, ! "%02ld", pt, ptlim); continue; case 'c': { *************** *** 379,390 **** ** (ado, 1996-01-02) */ { ! int year; int yday; int wday; int w; ! year = t->tm_year + TM_YEAR_BASE; yday = t->tm_yday; wday = t->tm_wday; for ( ; ; ) { --- 381,393 ---- ** (ado, 1996-01-02) */ { ! long year; int yday; int wday; int w; ! year = t->tm_year; ! year += TM_YEAR_BASE; yday = t->tm_yday; wday = t->tm_wday; for ( ; ; ) { *************** *** 426,436 **** DAYSPERNYEAR; } #ifdef XPG4_1994_04_09 ! if ((w == 52 ! && t->tm_mon == TM_JANUARY) ! || (w == 1 ! && t->tm_mon == TM_DECEMBER)) ! w = 53; #endif /* defined XPG4_1994_04_09 */ if (*format == 'V') pt = _conv(w, "%02d", --- 429,439 ---- DAYSPERNYEAR; } #ifdef XPG4_1994_04_09 ! if ((w == 52 && ! t->tm_mon == TM_JANUARY) || ! (w == 1 && ! t->tm_mon == TM_DECEMBER)) ! w = 53; #endif /* defined XPG4_1994_04_09 */ if (*format == 'V') pt = _conv(w, "%02d", *************** *** 437,446 **** pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(year % 100, "%02d", pt, ptlim); - } else pt = _conv(year, "%04d", - pt, ptlim); } continue; case 'v': --- 440,449 ---- pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(int(year % 100), ! "%02d", pt, ptlim); ! } else pt = _lconv(year, "%04ld", pt, ptlim); } continue; case 'v': *************** *** 477,488 **** continue; case 'y': *warnp = IN_ALL; ! pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, "%02d", pt, ptlim); continue; case 'Y': ! pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! pt, ptlim); continue; case 'Z': #ifdef TM_ZONE --- 480,493 ---- continue; case 'y': *warnp = IN_ALL; ! pt = _conv( ! (int) ((t->tm_year + ! (long) TM_YEAR_BASE) % 100), "%02d", pt, ptlim); continue; case 'Y': ! pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, ! "%04ld", pt, ptlim); continue; case 'Z': #ifdef TM_ZONE *************** *** 582,587 **** --- 587,605 ---- char buf[INT_STRLEN_MAXIMUM(int) + 1]; (void) sprintf(buf, format, n); + return _add(buf, pt, 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); }

2 2

GMT time
by Miss k Weir Sept. 3, 2004

Sept. 3, 2004

please give details of gmt time difference round the world

1 0

FW: Definition of time_t changed from signed to unsigned...
by Olson, Arthur David (NIH/NCI) Aug. 20, 2004

Aug. 20, 2004

Susan Richards is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Susan Richards [mailto:cj_richards@hotmail.com] Sent: Wednesday, August 18, 2004 12:58 PM To: clive(a)demon.net; guy(a)alum.mit.edu Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Definition of time_t changed from signed to unsigned... Hello All, I have another (potentially stupid) question regarding the interaction of NTP, leap seconds and the timezone database: As I've been going through the TZ code, I've seen the leap correction code. It appears that the adjustment for leap seconds is made when converting the UTC system time (which includes leap seconds) to POSIX (which does not) or visa versa. So my understanding is:- UTC - includes leap seconds POSIX - no leap seconds included. Is this correct? If my system is maintaining UTC (as set by some NTP server), and running the timezone database code, then are my following assumptions correct: 1) The result of calling time(0) is UTC (as maintained by NTP) and does include leap seconds. 2) The date & time displayed using "date" also takes into account leap seconds. 3) If I want to report POSIX time, I need to call time2posix(). Thanks for your time. Chris. From: "Clive D.W. Feather" <clive(a)demon.net> To: Guy Harris <guy(a)alum.mit.edu> CC: Chris Richards <cj_richards(a)hotmail.com>, Tz <tz(a)lecserver.nci.nih.gov> Subject: Re: Definition of time_t changed from signed to unsigned... Date: Tue, 20 Jul 2004 09:30:31 +0100 Guy Harris said: >>> If you can, I'd change the time_t typedef in the OS. >> Changing an OS-supplied definition is EXTREMELY DUMB. You're risking >> breaking the OS interfaces. > When he said "I am in the process of upgrading the kernel version on a > platform that I > work on.", it sounded as if he might be one of the developers *of* that > platform In which case it's a very different kettle of fish, I agree. I read the original thread as suggesting just changing the header file available to user code and reacted accordingly - that remains extremely dumb. Changing the OS's own definitions is, of course, completely different. If I've reacted over nothing, I apologise to all concerned. -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee(r) Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 5

Re: The year before the year 1
by Paul Eggert Aug. 19, 2004

Aug. 19, 2004

"Olson, Arthur David (NIH/NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > it's a localtime/gmtime issue (how to set the value of tm_year for > given time_t inputs). In any event...can you point me at chapter on > verse from the C standard on this? The C standard says that the semantics of tm_year is "years since 1900". It gives no normal range limit (unlike other members like tm_mon, where it lists a normal range limit of [0,11]), so presumably the valid values for tm_year are INT_MIN..INT_MAX. However, the standard has no explicit statement that tm_year == -1 stands for 1899, and I guess that one could argue that the word "since" implies a nonnegative value and that the behavior is undefined when tm_year is negative. However, I don't know of any implementation where -1 stands for anything other than 1899 (the only obvious value). If we assume this, then -2 stands for 1898, ..., -1899 stands for the year 1, and -1900 stands for the year 0 (or the year 1 B.C., if you prefer the Venerable Bede's notation). This is true on all implementations that I know of, at least as far as localtime/gmtime goes (typically on 64-bit hosts). For strftime the issue is not so clear: please see my next message.

1 0

Re: Definition of time_t changed from signed to unsigned...
by Bradley White Aug. 19, 2004

Aug. 19, 2004

Susan (Chris?) Richards asked: > As I've been going through the TZ code, I've seen the leap correction code. > It appears that the adjustment for leap seconds is made when converting the > UTC system time (which includes leap seconds) to POSIX (which does not) or > visa versa. The adjustment for leap seconds is made when converting a time_t to a struct tm. > So my understanding is:- > UTC - includes leap seconds An ado "right" time_t includes leap seconds (i.e., it keeps ticking through leap events). > POSIX - no leap seconds included. A POSIX time_t uses 86400-second days (i.e., the system time must be adjusted during leap events). > If my system is maintaining UTC (as set by some NTP server), and running > the timezone database code, then are my following assumptions correct: > > 1) The result of calling time(0) is UTC (as maintained by NTP) and does > include leap seconds. If you are running in "right" mode, time(0) returns a "right" time_t. "posix" mode, of course, results in a POSIX time_t. Given that NTP uses POSIX-like timestamps, a call to time2posix() needs to be added to NTP in order for it to correctly synchronize an ado "right" system (after which it can also ignore leap warnings). > 2) The date & time displayed using "date" also takes into account leap > seconds. "date" always displays the civil time. A non-"right" system will show a discontinuity over a leap event, however. > 3) If I want to report POSIX time, I need to call time2posix(). Correct ... time2posix() always returns a POSIX time_t whether you are running in "right" mode or not. Bradley

1 0

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

Aug. 12, 2004

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

3 2

proposed patch to difftime.c and Makefile for tz code
by Paul Eggert Aug. 11, 2004

Aug. 11, 2004

Here's a proposed patch to difftime.c and Makefile to reflect all the recent back-and-forth between Clive D.W. Feather and myself. The main practical import of this patch is the avoidance of a double-rounding bug on hosts with 64-bit time_t and 64-bit 'long double', but it also fixes some much-bigger errors on unusual hosts that have holes in their integer representations. Thanks, Clive! *** Makefile 2004/08/11 15:59:05 2004.3 --- Makefile 2004/08/11 20:30:07 2004.3.0.1 *************** LDLIBS= *** 87,105 **** # Add the following to the end of the "CFLAGS=" line as needed. # -Dconst= if `const' does not work (SunOS 4.x cc, OSF1 V5.0 cc) # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS # -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard (Solaris 8). ! # -DHAVE_LONG_DOUBLE=1 if your compiler supports the `long double' type # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) # -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD) # -DHAVE_SETTIMEOFDAY=3 if settimeofday ignores 2nd arg (4.4BSD) # -DHAVE_STRERROR=0 if your system lacks the strerror function # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if your compiler lacks a "sys/stat.h" # -DHAVE_SYS_WAIT_H=0 if your compiler lacks a "sys/wait.h" # -DLOCALE_HOME=\"path\" if locales are in "path", not "/usr/lib/locale" # -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?) # -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h" --- 87,110 ---- # Add the following to the end of the "CFLAGS=" line as needed. # -Dconst= if `const' does not work (SunOS 4.x cc, OSF1 V5.0 cc) + # -Duintmax='unsigned long long int' if your pre-C99 compiler has such a type # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS # -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard (Solaris 8). ! # -DHAVE_LONG_DOUBLE=1 if your pre-C89 compiler has the `long double' type # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) # -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD) # -DHAVE_SETTIMEOFDAY=3 if settimeofday ignores 2nd arg (4.4BSD) + # -DHAVE_STDINT_H=1 if your pre-C99 compiler has a "stdint.h" # -DHAVE_STRERROR=0 if your system lacks the strerror function # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if your compiler lacks a "sys/stat.h" # -DHAVE_SYS_WAIT_H=0 if your compiler lacks a "sys/wait.h" + # -DINTMAX_MAX=9223372036854775807 (or to the greatest signed integer, + # whatever it is) if your compiler lacks INTMAX_MAX, and if LLONG_MAX + # (or LONG_MAX, if LLONG_MAX is not defined) is not the greatest # -DLOCALE_HOME=\"path\" if locales are in "path", not "/usr/lib/locale" # -DHAVE_UNISTD_H=0 if your compiler lacks a "unistd.h" (Microsoft C++ 7?) # -DHAVE_UTMPX_H=1 if your compiler has a "utmpx.h" *** difftime.c 2002/01/28 15:36:25 2002.2 --- difftime.c 2004/08/11 20:13:16 2002.2.0.3 *************** static char elsieid[] = "@(#)difftime.c *** 14,83 **** #include "private.h" /* ! ** Algorithm courtesy Paul Eggert (eggert(a)twinsun.com) */ ! #ifdef HAVE_LONG_DOUBLE ! #define long_double long double ! #endif /* defined HAVE_LONG_DOUBLE */ #ifndef HAVE_LONG_DOUBLE ! #define long_double double #endif /* !defined HAVE_LONG_DOUBLE */ double difftime(time1, time0) ! const time_t time1; ! const time_t time0; { ! time_t delta; ! time_t hibit; - { - time_t tt; - double d; - long_double ld; - - if (sizeof tt < sizeof d) - return (double) time1 - (double) time0; - if (sizeof tt < sizeof ld) - return (long_double) time1 - (long_double) time0; - } - if (time1 < time0) - return -difftime(time0, time1); - /* - ** As much as possible, avoid loss of precision - ** by computing the difference before converting to double. - */ - delta = time1 - time0; - if (delta >= 0) - return delta; /* ! ** Repair delta overflow. */ ! hibit = (~ (time_t) 0) << (TYPE_BIT(time_t) - 1); /* ! ** The following expression rounds twice, which means ! ** the result may not be the closest to the true answer. ! ** For example, suppose time_t is 64-bit signed int, ! ** long_double is IEEE 754 double with default rounding, ! ** time1 = 9223372036854775807 and time0 = -1536. ! ** Then the true difference is 9223372036854777343, ! ** which rounds to 9223372036854777856 ! ** with a total error of 513. ! ** But delta overflows to -9223372036854774273, ! ** which rounds to -9223372036854774784, and correcting ! ** this by subtracting 2 * (long_double) hibit ! ** (i.e. by adding 2**64 = 18446744073709551616) ! ** yields 9223372036854776832, which ! ** rounds to 9223372036854775808 ! ** with a total error of 1535 instead. ! ** This problem occurs only with very large differences. ! ** It's too painful to fix this portably. ! ** We are not alone in this problem; ! ** some C compilers round twice when converting ! ** large unsigned types to small floating types, ! ** so if time_t is unsigned the "return delta" above ! ** has the same double-rounding problem with those compilers. */ ! return delta - 2 * (long_double) hibit; } --- 14,175 ---- #include "private.h" /* ! ** Algorithm courtesy Paul Eggert (eggert(a)cs.ucla.edu) ! ** ! ** Most other code assumes that time_t is an integer type without ! ** padding bits, and that integer arithmetic is modular two's ! ** complement without overflow traps, but (just for fun) this works ! ** even if time_t is an integer type with padding bits, or a real ! ** floating type, and it works even if signed integer overflow ! ** has undefined behavior. */ ! #include <float.h> ! ! #define TYPE_FLOATING(type) ((type) 0.4 != 0) ! ! #if !defined HAVE_LONG_DOUBLE && defined __STDC__ ! #define HAVE_LONG_DOUBLE 1 ! #endif /* !defined HAVE_LONG_DOUBLE && defined __STDC__ */ #ifndef HAVE_LONG_DOUBLE ! #define HAVE_LONG_DOUBLE 0 #endif /* !defined HAVE_LONG_DOUBLE */ + #if HAVE_LONG_DOUBLE + #define long_double long double + #endif /* HAVE_LONG_DOUBLE */ + #if !HAVE_LONG_DOUBLE + #define long_double double + #endif /* !HAVE_LONG_DOUBLE */ + + #ifndef HAVE_STDINT_H + #define HAVE_STDINT_H (199901L <= __STDC_VERSION__) + #endif /* !defined HAVE_STDINT_H */ + + #if HAVE_STDINT_H + #include <stdint.h> + #define uintmax uintmax_t + #endif /* HAVE_STDINT_H */ + #if !defined uintmax && defined ULLONG_MAX + #define uintmax unsigned long long int + #endif /* !defined uintmax && defined ULLONG_MAX */ + #ifndef uintmax + #define uintmax unsigned long int + #endif /* defined uintmax */ + + #ifndef UINTMAX_MAX + #define UINTMAX_MAX ((uintmax) -1) + #endif /* !defined UINTMAX_MAX */ + + #if !defined INTMAX_MAX && defined LLONG_MAX + #define INTMAX_MAX LLONG_MAX + #endif /* !defined INTMAX_MAX && defined LLONG_MAX */ + #ifndef INTMAX_MAX + #define INTMAX_MAX LONG_MAX + #endif /* !defined INTMAX_MAX */ + double difftime(time1, time0) ! time_t time1; ! time_t time0; { ! int time1_is_smaller; ! double delta; /* ! ** Use floating point if there should be no double-rounding error. ! ** However, avoid long double if it must be wider than needed, ! ** as it's sometimes much more expensive in these cases ! ** (e.g., 64-bit sparc). */ ! if (TYPE_BIT(time_t) <= DBL_MANT_DIG ! || (TYPE_FLOATING(time_t) ! && sizeof(time_t) < sizeof(long_double))) { ! double t1 = time1; ! double t0 = time0; ! return t1 - t0; ! } ! if ((TYPE_BIT(time_t) <= LDBL_MANT_DIG ! && (TYPE_BIT(time_t) == LDBL_MANT_DIG ! || (TYPE_SIGNED(time_t) && UINTMAX_MAX / 2 < INTMAX_MAX))) ! || TYPE_FLOATING(time_t)) { ! long_double t1 = time1; ! long_double t0 = time0; ! return t1 - t0; ! } ! ! time1_is_smaller = time1 < time0; ! if (time1_is_smaller) { ! time_t t = time1; ! time0 = time1; ! time1 = t; ! } ! /* ! ** Now time0 <= time1, and time_t is an integer type. ! ** Optimize the common special cases where time_t is unsigned, ! ** or can be converted to uintmax without losing information. */ ! if (! TYPE_SIGNED(time_t)) ! delta = time1 - time0; ! else { ! uintmax t1 = time1; ! uintmax t0 = time0; ! uintmax dt = t1 - t0; ! delta = dt; ! if (UINTMAX_MAX / 2 < INTMAX_MAX) { ! /* ! ** uintmax has padding bits, and time_t is signed. ! ** Check for overflow: compare dt/2 to (time1/2 - ! ** time0/2). Overflow occurred if they differ by ! ** more than a small slop. ! ** ! ** Thanks to Clive D.W. Feather for detailed technical ! ** advice about hosts with padding bits. ! */ ! uintmax hdt = dt / 2; ! time_t ht1 = time1 / 2; ! time_t ht0 = time0 / 2; ! time_t dht = ht1 - ht0; ! /* ! ** "h" here means half. By range analysis, we have: ! ** -0.5 <= ht1 - time1/2 <= 0.5 ! ** -0.5 <= ht0 - time0/2 <= 0.5 ! ** -1.0 <= dht - (time1 - time0)/2 <= 1.0 ! ** If overflow has not occurred, we also have: ! ** -0.5 <= hdt - (time1 - time0)/2 <= 0 ! ** -1.0 <= dht - hdt <= 1.5 ! ** and since dht - hdt is an integer, we also have: ! ** -1 <= dht - hdt <= 1 ! ** or equivalently: ! ** 0 <= dht - hdt + 1 <= 2 ! ** In the above analysis, all the operators have ! ** their exact mathematical semantics, not C semantics. ! ** However, dht - hdt + 1 is unsigned in C, ! ** so it need not be compared to zero. ! */ ! if (2 < dht - hdt + 1) { ! /* ! ** Repair delta overflow. ! ** ! ** The following expression contains a second ! ** rounding, so the result may not be the ! ** closest to the true answer. This problem ! ** occurs only with very large differences, ! ** It's too painful to fix this portably. ! ** We are not alone in this problem; some C ! ** compilers round twice when converting ! ** large unsigned types to small floating ! ** types, so if time_t is unsigned the ! ** "delta = dt" above has the same ! ** double-rounding problem with those ! ** compilers. ! */ ! long_double hibit = ~(UINTMAX_MAX / 2); ! delta = dt + 2 * hibit; ! } ! } ! } ! ! return time1_is_smaller ? -delta : delta; }

1 0

The year before the year 1
by Olson, Arthur David (NIH/NCI) Aug. 11, 2004

Aug. 11, 2004

One of Paul's documentation changes that I left out of the update was... +The year before the year 1 is the year 0, the year before that is +the year \-1, and so forth. If I recall correctly, there's no year zero: the sequence (going backward) is... 3 AD, 2 AD, 1 AD, 1 BC, 2 BC, 3 BC... ...or, for "Common Era" fans... 3 CE, 2 CE, 1 CE, 1 BCE, 2 BCE, 3 BCE.. Have our standard-making friends said anything on the matter? --ado

3 2

Tzcode2004c.tar.gz
by Olson, Arthur David (NIH/NCI) Aug. 11, 2004

Aug. 11, 2004

The file... ftp://elsie.nci.nih.gov/tzcode2004c.tar.gz ...is now available; this includes the asctime-related changes circulated on the time zone mailing list last week as well as (variants of) some of the documentation changes suggested by Paul Eggert. No new data tarball has been made available since none of the data tarball components have changed. --ado

1 0

Difftime code
by Clive D. W. Feather Aug. 10, 2004

Aug. 10, 2004

Okay, I've looked at the problem a bit. I also note that there's some portability problems in the code in 2004b. In particular, if time_t is a signed integer type then the calculation of delta can involve undefined behaviour; you cannot assume twos-complement unflagged wrap-around in signed integer types. time_t has to be either an integer type or a real-floating type [C99 allows it to be a complex-floating type, but POSIX doesn't]. We can easily distinguish these cases: if ((time_t) 0.2 != (time_t) 0.4) // It's a real-floating type else // It's an integer type If it's real-floating, then: return (long double) time1 - time0; is as accurate as you can get: the subtraction is done in long double (the conversion to this is lossless) and the rounding to double happens at the end. If it's integer, it's a bit harder; I'll assume for simplicity that time1>time0. if (time0 >= 0 || time1 < 0) return time1 - time0; In this case, the subtraction won't overflow; if the result is representable, it'll be rounded at the end. In the remaining case, a simple subtraction could overflow and you're in trouble. So we need to find the "top type": * on a C99 implementation, this is uintmax_t; * on a C89 implementation, this is unsigned long; * on non-conforming implementations you have a problem, but the most likely case is unsigned long or unsigned long long. #if __STDC__ == 1 && __STDC_VERSION__ >= 199901L #define HAVE_UINTMAX_T #endif #ifdef HAVE_UINTMAX_T #include <stdint.h> typedef uintmax_t top_type; #else #ifdef HAVE_LONG_LONG typedef unsigned long long top_type; #else typedef unsigned long top_type; #endif #endif This code works correctly on C89 and C99 conforming implementations, but you may have to tune it for others. If we now cast the two values to (top_type) and subtract, we get a value which is either: time1 - time0 OR time1 - time0 - BASIS (BASIS is 2 to the power N, where N is the number of bits in top_type). The latter case can only happen if top_type has the same number of *value* bits as time_t and so has the same maximum value, *and* the subtraction overflows. time_t s4 = time1 / 4 - time0 / 4; top_type dt = (top_type) time1 - (top_type) time0; top_type t4 = dt / 4; At this point, t4 is either approximately equal to s4, in which case dt is correct, or the right answer is dt + BASIS, in which case t4 is approximately s4 - BASIS / 4. So: if (t4 > s4 - (top_type)-1 / 8) return dt; So now we can't stay in integer types to calculate the entire value. Rather, we need to do dt + BASIS in long double. top_type halfBASIS = (top_type)-1 / 2 + 1; return 2.0L * halfBASIS + dt; I'm not in a position to do a full analysis, but let me note that we're adding two positive values, so you don't have the issues you do with subtraction and the addition can only lose 1ulp of precision. Furthermore, on a binary machine the first operand can be represented exactly. So, putting that all together and making some cosmetic changes and minor optimisations: #if __STDC__ == 1 // and the implementation isn't lying about this #if __STDC_VERSION >= 199901L #include <stdint.h> typedef uintmax_t top_type; #else typedef unsigned long top_type; #endif typedef long double long_double; #else // You'll have to fill this in using your own portability guidelines typedef ???? top_type; // The widest range unsigned integer type typedef ???? long_double; // The widest range floating-point type #endif double difftime (const time_t time1, const time_t time0) { time_t s4; top_type dt; if ((time_t) 0.2 != (time_t) 0.4) return (long_double) time1 - time0; if (time1 < time0) return -difftime (time0, time1); if (time0 >= 0 || time1 < 0) return time1 - time0; s4 = (time1 >> 2) - time0 / 4; // time0 < 0, so >> is a bad idea dt = (top_type) time1 - (top_type) time0; if ((dt >> 2) > s4 - ((top_type)-1 >> 3)) return dt; return (long_double) 2 * ~((top_type)-1 >> 1) + dt; } If you don't like this approach, then I have one other suggestion. Rather than using sizeof as a placeholder for the precision of various types, you can use the values FLT_RADIX and LDBL_MANT_DIG (in <float.h>) to calculate the largest integer that can be represented exactly in long double: static long double maxLDint = 0.0; if (maxLDint < 100.0) { int i; for (i = 0; i < LDBL_MANT_DIG; i++) maxLDint = maxLDint * FLT_RADIX + (FLT_RADIX - 1); } But you still need to address some of your other bugs in your code. -- Clive D.W. Feather | Internet Expert | Work: <clive(a)demon.net> Tel: +44 20 8495 6138 | Demon Internet | Home: <clive(a)davros.org> Fax: +44 870 051 9937 | Thus plc | Web: <http://www.davros.org> Please reply to the Reply-To address, which is: <clive(a)demon.net>

3 8

RE: Proposed asctime-related changes
by Olson, Arthur David (NIH/NCI) Aug. 10, 2004

Aug. 10, 2004

> First, GCC warns about zdump.c's new signed-versus-unsigned comparisons "timeptr->tm_wday >= sizeof ...." and similarly for tm_mon. > The comparisons aren't needed here, since the values are guaranteed to be in range, so the easiest fix is to remove them. The packaged versions of localtime and gmtime always return in-range values for tm_wday and tm_mon. However, zdump.c might be compiled with a version of localtime or gmtime that does something evil, so defensive programming may be in order. Casts along the lines shown below should do the trick. --ado if (timeptr->tm_wday < 0 || timeptr->tm_wday >= (int) (sizeof wday_name / sizeof wday_name[0])) wn = "???"; else wn = wday_name[timeptr->tm_wday]; if (timeptr->tm_mon < 0 || timeptr->tm_mon >= (int) (sizeof mon_name / sizeof mon_name[0])) mn = "???"; else mn = mon_name[timeptr->tm_mon];

3 5

FW: Chinese timezones do not observe DST
by Olson, Arthur David (NIH/NCI) Aug. 9, 2004

Aug. 9, 2004

Since sending this message, Alexandru Pulbere has been added to the time zone mailing list. --ado _____ From: Pulbere, Alexandru [mailto:Alexandru.Pulbere@cognos.com] Sent: Thursday, August 05, 2004 6:56 PM To: tz(a)lecserver.nci.nih.gov Subject: Chinese timezones do not observe DST I noticed that the timezone description for chinese timezones use DST. Aparently the chinese governament stopped using DST in 1992. To fix the problem I changed my copy asia file and regenerated ICU4J resources (my copy). # China # From Guy Harris: # People's Republic of China. Yes, they really have only one time zone. # From Bob Devine (1988-01-28): # No they don't. See TIME mag, 1986-02-17 p.52. Even though # China is across 4 physical time zones, before Feb 1, 1986 only the # Peking (Bejing) time zone was recognized. Since that date, China # has two of 'em -- Peking's and Urumqi (named after the capital of # the Xinjiang Uyghur Autonomous Region). I don't know about DST for it. # # . . .I just deleted the DST table and this editor makes it too # painful to suck in another copy.. So, here is what I have for # DST start/end dates for Peking's time zone (info from AP): # # 1986 May 4 - Sept 14 # 1987 mid-April - ?? # From U. S. Naval Observatory (1989-01-19): # CHINA 8 H AHEAD OF UTC ALL OF CHINA, INCL TAIWAN # CHINA 9 H AHEAD OF UTC APR 17 - SEP 10 # From Paul Eggert <eggert(a)twinsun.com> (1995-12-19): # Shanks writes that China has had a single time zone since 1980 May 1, # observing summer DST from 1986 through 1991; this contradicts Devine's # note about Time magazine, though apparently _something_ happened in 1986. # Go with Shanks for now. I made up names for the other pre-1980 time zones. # From Shanks: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Shang 1940 only - Jun 3 0:00 1:00 D Rule Shang 1940 1941 - Oct 1 0:00 0 S Rule Shang 1941 only - Mar 16 0:00 1:00 D Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D # # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # From Anthony Fok (2001-12-20): # BTW, I did some research on-line and found some info regarding these five # historic timezones from some Taiwan websites. And yes, there are official # Chinese names for these locales (before 1949): # Changbai Time ("Long-white Time", Long-white = Heilongjiang area) Zone Asia/Harbin 8:26:44 - LMT 1928 # or Haerbin 8:30 - CHAT 1932 Mar # Changbai Time 8:00 - CST 1940 9:00 - CHAT 1966 May 8:30 - CHAT 1980 May 8:00 PRC C%sT 1992 8:00 - CST # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT 1992 8:00 - CST # Long-shu Time (probably due to Long and Shu being two names of that area) Zone Asia/Chongqing 7:06:20 - LMT 1928 # or Chungking 7:00 - LONT 1980 May # Long-shu Time 8:00 PRC C%sT 1992 8:00 - CST # Xin-zang Time ("Xinjiang-Tibet Time") Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time 8:00 PRC C%sT 1992 8:00 - CST # Kunlun Time Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May 8:00 PRC C%sT 1992 8:00 - CST # Hong Kong (Xianggang) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule HK 1946 only - Apr 20 3:30 1:00 S Rule HK 1946 only - Dec 1 3:30 0 - Rule HK 1947 only - Apr 13 3:30 1:00 S Rule HK 1947 only - Dec 30 3:30 0 - Rule HK 1948 only - May 2 3:30 1:00 S Rule HK 1948 1952 - Oct lastSun 3:30 0 - Rule HK 1949 1953 - Apr Sun>=1 3:30 1:00 S Rule HK 1953 only - Nov 1 3:30 0 - Rule HK 1954 1964 - Mar Sun>=18 3:30 1:00 S Rule HK 1954 only - Oct 31 3:30 0 - Rule HK 1955 1964 - Nov Sun>=1 3:30 0 - Rule HK 1965 1977 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1977 - Oct Sun>=16 3:30 0 - Rule HK 1979 1980 - May Sun>=8 3:30 1:00 S Rule HK 1979 1980 - Oct Sun>=16 3:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Hong_Kong 7:36:36 - LMT 1904 Oct 30 8:00 HK HK%sT 2002 8:00 - CST ############################################################################ ### # Taiwan # Shanks writes that Taiwan observed DST during 1945, when it # was still controlled by Japan. This is hard to believe, but we don't # have any other information. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Taiwan 1945 1951 - May 1 0:00 1:00 D Rule Taiwan 1945 1951 - Oct 1 0:00 0 S Rule Taiwan 1952 only - Mar 1 0:00 1:00 D Rule Taiwan 1952 1954 - Nov 1 0:00 0 S Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D Rule Taiwan 1955 1961 - Oct 1 0:00 0 S Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D Rule Taiwan 1974 1975 - Oct 1 0:00 0 S Rule Taiwan 1980 only - Jun 30 0:00 1:00 D Rule Taiwan 1980 only - Sep 30 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Taipei 8:06:00 - LMT 1896 # or Taibei or T'ai-pei 8:00 Taiwan C%sT 1992 8:00 - CST # Macau (Macao, Aomen) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Macau 1961 1962 - Mar Sun>=16 3:30 1:00 S Rule Macau 1961 1964 - Nov Sun>=1 3:30 0 - Rule Macau 1963 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1964 only - Mar Sun>=16 3:30 1:00 S Rule Macau 1965 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1965 only - Oct 31 0:00 0 - Rule Macau 1966 1971 - Apr Sun>=16 3:30 1:00 S Rule Macau 1966 1971 - Oct Sun>=16 3:30 0 - Rule Macau 1972 1974 - Apr Sun>=15 0:00 1:00 S Rule Macau 1972 1973 - Oct Sun>=15 0:00 0 - Rule Macau 1974 1977 - Oct Sun>=15 3:30 0 - Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 - CST This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.

2 1

Chinese timezones do not observe DST
by Pulbere, Alexandru Aug. 5, 2004

Aug. 5, 2004

I noticed that the timezone description for chinese timezones use DST. Aparently the chinese governament stopped using DST in 1992. To fix the problem I changed my copy asia file and regenerated ICU4J resources (my copy). # China # From Guy Harris: # People's Republic of China. Yes, they really have only one time zone. # From Bob Devine (1988-01-28): # No they don't. See TIME mag, 1986-02-17 p.52. Even though # China is across 4 physical time zones, before Feb 1, 1986 only the # Peking (Bejing) time zone was recognized. Since that date, China # has two of 'em -- Peking's and Urumqi (named after the capital of # the Xinjiang Uyghur Autonomous Region). I don't know about DST for it. # # . . .I just deleted the DST table and this editor makes it too # painful to suck in another copy.. So, here is what I have for # DST start/end dates for Peking's time zone (info from AP): # # 1986 May 4 - Sept 14 # 1987 mid-April - ?? # From U. S. Naval Observatory (1989-01-19): # CHINA 8 H AHEAD OF UTC ALL OF CHINA, INCL TAIWAN # CHINA 9 H AHEAD OF UTC APR 17 - SEP 10 # From Paul Eggert <eggert(a)twinsun.com> (1995-12-19): # Shanks writes that China has had a single time zone since 1980 May 1, # observing summer DST from 1986 through 1991; this contradicts Devine's # note about Time magazine, though apparently _something_ happened in 1986. # Go with Shanks for now. I made up names for the other pre-1980 time zones. # From Shanks: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Shang 1940 only - Jun 3 0:00 1:00 D Rule Shang 1940 1941 - Oct 1 0:00 0 S Rule Shang 1941 only - Mar 16 0:00 1:00 D Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D # # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # From Anthony Fok (2001-12-20): # BTW, I did some research on-line and found some info regarding these five # historic timezones from some Taiwan websites. And yes, there are official # Chinese names for these locales (before 1949): # Changbai Time ("Long-white Time", Long-white = Heilongjiang area) Zone Asia/Harbin 8:26:44 - LMT 1928 # or Haerbin 8:30 - CHAT 1932 Mar # Changbai Time 8:00 - CST 1940 9:00 - CHAT 1966 May 8:30 - CHAT 1980 May 8:00 PRC C%sT 1992 8:00 - CST # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT 1992 8:00 - CST # Long-shu Time (probably due to Long and Shu being two names of that area) Zone Asia/Chongqing 7:06:20 - LMT 1928 # or Chungking 7:00 - LONT 1980 May # Long-shu Time 8:00 PRC C%sT 1992 8:00 - CST # Xin-zang Time ("Xinjiang-Tibet Time") Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time 8:00 PRC C%sT 1992 8:00 - CST # Kunlun Time Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May 8:00 PRC C%sT 1992 8:00 - CST # Hong Kong (Xianggang) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule HK 1946 only - Apr 20 3:30 1:00 S Rule HK 1946 only - Dec 1 3:30 0 - Rule HK 1947 only - Apr 13 3:30 1:00 S Rule HK 1947 only - Dec 30 3:30 0 - Rule HK 1948 only - May 2 3:30 1:00 S Rule HK 1948 1952 - Oct lastSun 3:30 0 - Rule HK 1949 1953 - Apr Sun>=1 3:30 1:00 S Rule HK 1953 only - Nov 1 3:30 0 - Rule HK 1954 1964 - Mar Sun>=18 3:30 1:00 S Rule HK 1954 only - Oct 31 3:30 0 - Rule HK 1955 1964 - Nov Sun>=1 3:30 0 - Rule HK 1965 1977 - Apr Sun>=16 3:30 1:00 S Rule HK 1965 1977 - Oct Sun>=16 3:30 0 - Rule HK 1979 1980 - May Sun>=8 3:30 1:00 S Rule HK 1979 1980 - Oct Sun>=16 3:30 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Hong_Kong 7:36:36 - LMT 1904 Oct 30 8:00 HK HK%sT 2002 8:00 - CST ######################################################################## ####### # Taiwan # Shanks writes that Taiwan observed DST during 1945, when it # was still controlled by Japan. This is hard to believe, but we don't # have any other information. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Taiwan 1945 1951 - May 1 0:00 1:00 D Rule Taiwan 1945 1951 - Oct 1 0:00 0 S Rule Taiwan 1952 only - Mar 1 0:00 1:00 D Rule Taiwan 1952 1954 - Nov 1 0:00 0 S Rule Taiwan 1953 1959 - Apr 1 0:00 1:00 D Rule Taiwan 1955 1961 - Oct 1 0:00 0 S Rule Taiwan 1960 1961 - Jun 1 0:00 1:00 D Rule Taiwan 1974 1975 - Apr 1 0:00 1:00 D Rule Taiwan 1974 1975 - Oct 1 0:00 0 S Rule Taiwan 1980 only - Jun 30 0:00 1:00 D Rule Taiwan 1980 only - Sep 30 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Taipei 8:06:00 - LMT 1896 # or Taibei or T'ai-pei 8:00 Taiwan C%sT 1992 8:00 - CST # Macau (Macao, Aomen) # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Macau 1961 1962 - Mar Sun>=16 3:30 1:00 S Rule Macau 1961 1964 - Nov Sun>=1 3:30 0 - Rule Macau 1963 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1964 only - Mar Sun>=16 3:30 1:00 S Rule Macau 1965 only - Mar Sun>=16 0:00 1:00 S Rule Macau 1965 only - Oct 31 0:00 0 - Rule Macau 1966 1971 - Apr Sun>=16 3:30 1:00 S Rule Macau 1966 1971 - Oct Sun>=16 3:30 0 - Rule Macau 1972 1974 - Apr Sun>=15 0:00 1:00 S Rule Macau 1972 1973 - Oct Sun>=15 0:00 0 - Rule Macau 1974 1977 - Oct Sun>=15 3:30 0 - Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 - CST This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.

1 0

Difftime code
by Clive D.W. Feather Aug. 5, 2004

Aug. 5, 2004

[Hmm, I don't think this got out properly yesterday.] Okay, I've looked at the problem a bit. I also note that there's some portability problems in the code in 2004b. In particular, if time_t is a signed integer type then the calculation of delta can involve undefined behaviour; you cannot assume twos-complement unflagged wrap-around in signed integer types. time_t has to be either an integer type or a real-floating type [C99 allows it to be a complex-floating type, but POSIX doesn't]. We can easily distinguish these cases: if ((time_t) 0.2 != (time_t) 0.4) // It's a real-floating type else // It's an integer type If it's real-floating, then: return (long double) time1 - time0; is as accurate as you can get: the subtraction is done in long double (the conversion to this is lossless) and the rounding to double happens at the end. If it's integer, it's a bit harder; I'll assume for simplicity that time1>time0. if (time0 >= 0 || time1 < 0) return time1 - time0; In this case, the subtraction won't overflow; if the result is representable, it'll be rounded at the end. In the remaining case, a simple subtraction could overflow and you're in trouble. So we need to find the "top type": * on a C99 implementation, this is uintmax_t; * on a C89 implementation, this is unsigned long; * on non-conforming implementations you have a problem, but the most likely case is unsigned long or unsigned long long. #if __STDC__ == 1 && __STDC_VERSION__ >= 199901L #define HAVE_UINTMAX_T #endif #ifdef HAVE_UINTMAX_T #include <stdint.h> typedef uintmax_t top_type; #else #ifdef HAVE_LONG_LONG typedef unsigned long long top_type; #else typedef unsigned long top_type; #endif #endif This code works correctly on C89 and C99 conforming implementations, but you may have to tune it for others. If we now cast the two values to (top_type) and subtract, we get a value which is either: time1 - time0 OR time1 - time0 - BASIS (BASIS is 2 to the power N, where N is the number of bits in top_type). The latter case can only happen if top_type has the same number of *value* bits as time_t and so has the same maximum value, *and* the subtraction overflows. time_t s4 = time1 / 4 - time0 / 4; top_type dt = (top_type) time1 - (top_type) time0; top_type t4 = dt / 4; At this point, t4 is either approximately equal to s4, in which case dt is correct, or the right answer is dt + BASIS, in which case t4 is approximately s4 - BASIS / 4. So: if (t4 > s4 - (top_type)-1 / 8) return dt; So now we can't stay in integer types to calculate the entire value. Rather, we need to do dt + BASIS in long double. top_type halfBASIS = (top_type)-1 / 2 + 1; return 2.0L * halfBASIS + dt; I'm not in a position to do a full analysis, but let me note that we're adding two positive values, so you don't have the issues you do with subtraction and the addition can only lose 1ulp of precision. Furthermore, on a binary machine the first operand can be represented exactly. So, putting that all together and making some cosmetic changes and minor optimisations: #if __STDC__ == 1 // and the implementation isn't lying about this #if __STDC_VERSION >= 199901L #include <stdint.h> typedef uintmax_t top_type; #else typedef unsigned long top_type; #endif typedef long double long_double; #else // You'll have to fill this in using your own portability guidelines typedef ???? top_type; // The widest range unsigned integer type typedef ???? long_double; // The widest range floating-point type #endif double difftime (const time_t time1, const time_t time0) { time_t s4; top_type dt; if ((time_t) 0.2 != (time_t) 0.4) return (long_double) time1 - time0; if (time1 < time0) return -difftime (time0, time1); if (time0 >= 0 || time1 < 0) return time1 - time0; s4 = (time1 >> 2) - time0 / 4; // time0 < 0, so >> is a bad idea dt = (top_type) time1 - (top_type) time0; if ((dt >> 2) > s4 - ((top_type)-1 >> 3)) return dt; return (long_double) 2 * ~((top_type)-1 >> 1) + dt; } If you don't like this approach, then I have one other suggestion. Rather than using sizeof as a placeholder for the precision of various types, you can use the values FLT_RADIX and LDBL_MANT_DIG (in <float.h>) to calculate the largest integer that can be represented exactly in long double: static long double maxLDint = 0.0; if (maxLDint < 100.0) { int i; for (i = 0; i < LDBL_MANT_DIG; i++) maxLDint = maxLDint * FLT_RADIX + (FLT_RADIX - 1); } But you still need to address some of your other bugs in your code. -- Clive D.W. Feather | Work: <clive(a)demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive(a)davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |

1 0

Re: asctime.c
by Olson, Arthur David (NIH/NCI) Aug. 5, 2004

Aug. 5, 2004

Thanks to all for feedback on asctime.c. The version below uses %02.2d for universality, uses %4ld for years to avoid problems if a year isn't four digits long, and avoids the use of snprintf (which isn't available on some systems). There are comments on all these changes. Is it soup yet? --ado /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson (arthur_david_olson(a)nih.gov) */ #ifndef lint #ifndef NOID static char elsieid[] = "@(#)asctime.c 7.15"; #endif /* !defined NOID */ #endif /* !defined lint */ /*LINTLIBRARY*/ #include "private.h" #include "tzfile.h" #define STANDARD_BUFFER_SIZE 26 /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * 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; /* ** 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). */ char result[2 * 3 + 5 * INT_STRLEN_MAXIMUM(int) + 3 + 2 + 1 + 1]; 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 format used in the (2004) standard is ** "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n" ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ** All years associated with 32-bit time_t values are exactly ** four digits long; some years associated with 64-bit time_t ** values are not four digits long so we throw in the 4 below. */ /* ** We avoid using snprintf since it's not available on all systems. */ (void) sprintf(result, "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %4ld\n", wn, mn, timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec, timeptr->tm_year + (long) TM_YEAR_BASE); if (strlen(result) >= STANDARD_BUFFER_SIZE) { errno = EOVERFLOW; return NULL; } else { (void) strcpy(buf, result); return buf; } } /* ** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. */ char * asctime(timeptr) register const struct tm * timeptr; { static char result[STANDARD_BUFFER_SIZE]; return asctime_r(timeptr, result); }

5 22