- tz - lists.iana.org

New rules for summer time in Brazil
by Paulo Alexandre Pinto Pires Oct. 4, 2004

Oct. 4, 2004

Dear folks, At last, Brazilian decree on summer time for 2004/2005 is out (it can be retrieved from Presidency website at <https://www.planalto.gov.br/ccivil_03/_Ato2004-2006/2004/Decreto/D5223.htm> and National Press web site at <http://www.in.gov.br/materias/xml/do/secao1/1187435.xml>). Innovations for this year include begining of summer time on a Tuesday (2004/11/02, that happens to be a religious holiday for mourning the dead). I *really* don't believe that this starting on Tuesday will last. States are the same as last year. If you have doubts, contact me. Regards, -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

2 2

FW: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 28, 2004

Sept. 28, 2004

Bradley White has quite rightly pointed out that sizeof's are no-no's in preprocessor directives. Of course it's possibly to simply... typedef long long raw_year_type; ...and use the defined type for year-holding variables to avoid problems with really big tm_year values. --ado

2 1

RE: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 28, 2004

Sept. 28, 2004

Another way to avoid problems with really big tm_year values would be to have something such as... #if (sizeof long) > (sizeof int) typedef long raw_year_type; #else typedef long long raw_year_type; #endif ...in the tzfile.h header file and then use the defined type for variables that hold results such as tmp->tm_year + TM_YEAR_BASE. It certainly makes for shorter code; as for the relative efficiency of long long arithmetic versus doubling the number of % operations being done, deponent sayeth not. --ado

1 0

RE: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 27, 2004

Sept. 27, 2004

At the end of this message you'll find proposed changes to strftime.c to do the right thing for wide-ranging years. I compiled it with this quick-and-dirty source code... #include "stdio.h" #include "sys/types.h" #include "time.h" static int years[] = { 10001, 10000, 9999, 1001, 1000, 999, 101, 100, 99, 11, 10, 9, 1, 0, -1, -9, -10, -11, -99, -100, -101, -999, -1000, -1001, -9999, -10000, -10001 }; #define NVALUES ((sizeof years) / (sizeof years[0])) static char * formats[] = { "%C", "%y", "%G", "%g" }; #define NFORMATS ((sizeof formats) / (sizeof formats[0])) #define TM_BASE_YEAR 1900 main() { static struct tm tm; int i; int j; char buf[1024]; tm.tm_mon = 0; /* months since January => January */ tm.tm_mday = 8; /* day of the month */ tm.tm_yday = 7; /* days since January 1 */ (void) printf("YEAR"); for (j = 0; j < NFORMATS; ++j) { (void) printf("\t%s", formats[j]); } (void) printf("\n"); for (i = 0; i < NVALUES; ++i) { (void) printf("%d", years[i]); tm.tm_year = years[i] - TM_BASE_YEAR; for (j = 0; j < NFORMATS; ++j) { (void) strftime(buf, sizeof buf, formats[j], &tm); (void) printf("\t%s", buf); } (void) printf("\n"); } return 0; } ...and got these results... YEAR %C %y %G %g 10001 100 01 10001 01 10000 100 00 10000 00 9999 99 99 9999 99 1001 10 01 1001 01 1000 10 00 1000 00 999 09 99 0999 99 101 01 01 0101 01 100 01 00 0100 00 99 00 99 0099 99 11 00 11 0011 11 10 00 10 0010 10 9 00 09 0009 09 1 00 01 0001 01 0 00 00 0000 00 -1 -0 01 -001 01 -9 -0 09 -009 09 -10 -0 10 -010 10 -11 -0 11 -011 11 -99 -0 99 -099 99 -100 -1 00 -100 00 -101 -1 01 -101 01 -999 -9 99 -999 99 -1000 -10 00 -1000 00 -1001 -10 01 -1001 01 -9999 -99 99 -9999 99 -10000 -100 00 -10000 00 -10001 -100 01 -10001 01 Absent any objections, I'll promulgate these changes next week (along with Paul Eggert's revised update to tz-link.htm). --ado ------- strftime.c ------- *** /tmp/geta12949 Thu Sep 23 15:27:03 2004 --- /tmp/getb12949 Thu Sep 23 15:27:03 2004 *************** *** 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". --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.69"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 217,225 **** ** something completely different. ** (ado, 1993-05-24) */ ! pt = _conv((int) ((t->tm_year + ! (long) TM_YEAR_BASE) / 100), ! "%02d", pt, ptlim); continue; case 'c': { --- 211,230 ---- ** something completely different. ** (ado, 1993-05-24) */ ! { ! long year; ! int top; ! ! year = t->tm_year; ! year += TM_YEAR_BASE; ! top = year / 100; ! if (top == 0 && year < 0) { ! pt = _add("-0", pt, ptlim); ! } else { ! pt = _conv(top, "%02d", ! pt, ptlim); ! } ! } continue; case 'c': { *************** *** 445,453 **** pt = _conv(w, "%02d", pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(int(year % 100), ! "%02d", pt, ptlim); } else pt = _lconv(year, "%04ld", pt, ptlim); } --- 450,464 ---- pt = _conv(w, "%02d", pt, ptlim); else if (*format == 'g') { + int i; + *warnp = IN_ALL; ! i = year % 100; ! if (i < 0) { ! i = -i; ! } ! pt = _conv(i, "%02d", ! pt, ptlim); } else pt = _lconv(year, "%04ld", pt, ptlim); } *************** *** 486,494 **** 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, --- 497,512 ---- continue; case 'y': *warnp = IN_ALL; ! { ! int i; ! ! i = (t->tm_year + ! (long) TM_YEAR_BASE) % 100; ! if (i < 0) { ! i = -i; ! } ! pt = _conv(i, "%02d", pt, ptlim); ! } continue; case 'Y': pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, *************** *** 556,564 **** diff = -diff; } else sign = "+"; pt = _add(sign, pt, ptlim); ! diff /= 60; ! pt = _conv((diff/60)*100 + diff%60, ! "%04d", pt, ptlim); } continue; case '+': --- 574,583 ---- diff = -diff; } else sign = "+"; pt = _add(sign, pt, ptlim); ! diff /= SECSPERMIN; ! diff = (diff / MINSPERHOUR) * 100 + ! (diff % MINSPERHOUR); ! pt = _conv(diff, "%04d", pt, ptlim); } continue; case '+':

3 5

Israel Timezone Changes -- 2005 and Beyond
by Ephraim Silverberg Sept. 26, 2004

Sept. 26, 2004

At 01:00 a.m. Wednesday (Israel Daylight Saving Time), Israel will move back to Standard Time (UTC+0200) as scheduled. However, this is the last legislated changeover date -- there are no official dates for 2005 and beyond. 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. If and when the law actually passes, I will post the necessary updates to timezone database to this forum. ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-5617723 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cse.huji.ac.il

1 1

Time Zone Database
by Craig Orput Sept. 23, 2004

Sept. 23, 2004

Is there anywhere on the Web where I can get a text file of the time zone database? I want to import into Excel but I can't seem to understand all this "TZ" stuff. Any help would be appreciated. thanks Craig Orput

1 0

Strftime's %C and %y formats versus wide-ranging tm_year values
by Olson, Arthur David (NIH/NCI) Sept. 22, 2004

Sept. 22, 2004

The current standard calls for strftime to produce these results: %C: Replaced by the year divided by 100 and truncated to an integer, as a decimal number [00,99]. %y: Replaced by the last two digits of the year as a decimal number [00,99]. The standard is fine where time_t values are 32 bits and the tm_year values associated with these time_t values are always positive, four-digit integers. We're now trying to cope with systems using 64-bit time_t values; the associated time_t values are much wider ranging. Below is a table with suggested %C and %y outputs for wide-ranging years. Note that: 1. %y is always in the range [00,99]. 2. %C is in the range [00,99] whenever possible. 3. %C is two characters long whenever possible. 4. Using the format "%C%y" produces the year in all cases (with leading zeroes in some cases). Is there a better solution? --ado tm_year %C %y ... 10001 100 01 10000 100 00 9999 99 99 ... 1001 10 01 1000 10 00 999 09 99 ... 101 01 01 100 01 00 99 00 99 ... 11 00 11 10 00 10 9 00 09 ... 1 00 01 0 00 00 -1 -0 01 ... -9 -0 09 -10 -0 10 -11 -0 11 ... -99 -0 99 -100 -1 00 -101 -1 01 ... -999 -9 99 -1000 -10 00 -1001 -10 01 ... -9999 -99 99 -10000 -100 00 -10001 -100 01 ...

2 1

Tzdata2004d.tar.gz
by Olson, Arthur David (NIH/NCI) Sept. 22, 2004

Sept. 22, 2004

The file... ftp://elsie.nci.nih.gov/pub/tzdata2004d.tar.gz ...is now available; this includes the changes circulated by Paul Eggert for Uruguay and the commentary on Israel, as well as the updates to tz-link.htm (modulo elimination of a space character). --ado

2 1

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