Tzcode2005a.tar.gz and tzdata2005a.tar.gz

The files
	ftp://elsie.nci.nih.gov/pub/tzcode2005a.tar.gz
and
	ftp://elsie.nci.nih.gov/pub/tzdata2005a.tar.gz
are now available. These incorporate the changes circulated in the last week
of 2004 on the time zone mailing list.

				--ado

Second part of localtime.c changes

Having dispensed with the easy stuff last week, below find the hard stuff.
The goal is to better behavior of localtime and gmtime on systems where
time_t is an exotic type--for example, a 64-bit integer or a double.
A problem is that the tm_year field of a "struct tm" field is, by standard,
an int--so there are some (very positive or very negative) time_t values
that can't be broken down into a "struct tm".
I've adopted existing practice here--localtime and gmtime return NULL in
such cases.

The system I'm using is a Sunblade 100 running gcc version 3.2.3. If I do a
"make typecheck" using version 7.85 of localtime.c and then do a "make
typecheck" using version 7.86, I get these differences:

	29,30c29,30
	< US/Eastern  Sat Oct 16 08:29:52 -1583348 UTC = Sat Oct 16 03:29:52
-1583348 EST isdst=0
	< US/Eastern  Sun Oct 17 08:29:52 -1583348 UTC = Sun Oct 17 03:29:52
-1583348 EST isdst=0
	---
	> US/Eastern  -9223372036854775808 = NULL
	> US/Eastern  -9223372036854689408 = NULL
	501,502c501,502
	< US/Eastern  Sun Mar 16 15:30:07 1587287 UTC = Sun Mar 16 10:30:07
1587287 EST isdst=0
	< US/Eastern  Mon Mar 17 15:30:07 1587287 UTC = Mon Mar 17 10:30:07
1587287 EST isdst=0
	---
	> US/Eastern  9223372036854689407 = NULL
	> US/Eastern  9223372036854775807 = NULL
	524,525c524,525

Paraguay timezone rules

There are several sources that claim that Paraguay made
a timezone rule change in autumn 2004, which not only
changed the date that Paraguay entered DST in 2004
but will also affect DST dates in 2005.

Steffen Thorsen on http://www.timeanddate.com claimed
that Paraguay entered DST in autumn 2004 Sunday the
17.th. of October and not Sunday 5.th. of September as
would have been predicted by the TZ database. Now in
2005 it claims that Paraguay will enter DST 
Sunday the 16.th. of October 2005 and not Sunday 4.th.
of September as it would be according to the TZ database.

I tried to verify this with some internet searches, but
could only find one source that interestingly is 
updating the TZ rules in a local version.
The source is http://avi.alkalay.net/linux/zoneinfo/Paraguay.txt
and it claims the following rule for Paraguay:

# Rule  NAME      FROM  TO     TYPE  IN    ON	     AT    SAVE
LETTER/S
Rule    Paraguay  2002  2003   -     Apr   Sun<=7    0:00  0      S
Rule    Paraguay  2002  2003   -     Sep   Sun<=7    0:00  1      D
Rule    Paraguay  2004  only   -     Apr   Sun<=7    0:00  0      S
Rule    Paraguay  2004  max    -     Oct   Sun>=15   0:00  1      D
Rule    Paraguay  2005  max    -     Mar   Sun>=8    0:00  0      S

The rule for "2004 to max" about when Paraguay enters DST, is
consistent with Steffen Thorsens dates for 2004 and 2005.
However, it also claims that Paraguay leaves DST at different 

leapseconds

Here's a (commentary-only) update to the leapseconds file to reflect the
IERS bulletin issued last year.

				--ado

------- leapseconds -------
*** /tmp/geta28966	Mon Jan  3 11:58:36 2005
--- /tmp/getb28966	Mon Jan  3 11:58:36 2005
***************
*** 1,4 ****
! #  <at> (#)leapseconds	7.17

  # Allowance for leapseconds added to each timezone file.

--- 1,4 ----
! #  <at> (#)leapseconds	7.18

  # Allowance for leapseconds added to each timezone file.

***************
*** 45,51 ****
  Leap	1998	Dec	31	23:59:60	+	S

  # 	INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS)
- # 
  # SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE
REFERENCE
  # 
  # SERVICE DE LA ROTATION TERRESTRE
--- 45,50 ----

Question on id stability

I have a couple of questions that I hope someone can give guidance on. These
are sparked by the change from IDs like "America/Catamarca" to
"America/Argentina/Catamarca"

In CLDR (http://unicode.org/cldr/), we are using the IDs to access different
localized names for the time zones. Each time a zone ID changes, we have the
choice of either updating all the localized files that use that ID, or
leaving them be and using the old ID. To make our maintenance easier (and
make it easier for implementations), I'm inclined to recommend that we
maintain stability as of a given date; that we never change an ID after that
point.

1. Would there be any downside to such a policy?

2. I was not able to find documentation as to whether there is a policy
disallowing 'retired' IDs to be reused later for a different timezone. Some
might think that it is so obviously a bad policy to reuse IDs that it
doesn't need stating, but ISO has reused country codes, for example, causing
no end of problems for stability.

3. What was the reason for the change for Argentina? Is this a one-off
aberration, or can we expect America/Chicago to change to America/United
States/Chicago, America/Vancouver to change to America/Canada/Vancouver, and
so on down the line?

4. Are links expected to be definitional and stable? That is, if I ever have
two IDs that are related by a link:

Link A B

Re: Question on id stability

"Mark Davis" <mark.davis <at> jtcsv.com> writes:

> I'm inclined to recommend that we maintain stability as of a given
> date; that we never change an ID after that point.
>
> 1. Would there be any downside to such a policy?

Only if somebody builds the database without the "backwards" file,
which lists the backwards-compatibility names.  The default is to
include "backwards", as it includes very common IDs like US/Pacific.
I'd be surprised (but not astonished) if someone omitted it.

> 2. I was not able to find documentation as to whether there is a policy
> disallowing 'retired' IDs to be reused later for a different timezone.

It's never happened in the past, and I'd be surprised if it needed to
happen in the future.  Backwards compatibility is a big deal.

> 3. What was the reason for the change for Argentina?

San Juan needed a (new) entry, and "America/San_Juan" would have been
too ambiguous: there are several other important San Juans in America.

> Is this a one-off aberration, or can we expect America/Chicago to
> change to America/United States/Chicago, America/Vancouver to change
> to America/Canada/Vancouver, and so on down the line?

I wouldn't rule it out, but I think it unlikely in our lifetimes.  If
it happens, we'll put in backwards-compatibility links.

Re: Question on id stability

<<On Mon, 03 Jan 2005 14:24:48 -0800, Paul Eggert <eggert <at> CS.UCLA.EDU> said:

> Only if somebody builds the database without the "backwards" file,
> which lists the backwards-compatibility names.  The default is to
> include "backwards", as it includes very common IDs like US/Pacific.
> I'd be surprised (but not astonished) if someone omitted it.

FreeBSD does not use "backwards":

----------------------------
revision 1.6
date: 1994/09/13 21:54:06;  author: wollman;  state: Exp;  lines: +36 -133
New method for installing timezone data files, not nearly as complicated
as the previous one, and better integrated with the build scheme.

Define OLDTIMEZONES to get backward-compatibility links added.
Define LEAPSECONDS if you want leap-second support.
=============================================================================

This change was made prior to the release of FreeBSD 2.0.  FreeBSD 1.x
(long obsolete) did support the old names.  (I don't recall whether it
supported the new names, but I suspect it didn't.)

-GAWollman

ISO-8601 3.25 Second, Leap Applications requiring leap seconds

Re: Question on id stability

On Monday, January 3 2005, "Paul Eggert" wrote to "Mark Davis, Tz (tz <at> elsie.nci.nih.gov)" saying:

> "Mark Davis" <mark.davis <at> jtcsv.com> writes:
> 
> > I'm inclined to recommend that we maintain stability as of a given
> > date; that we never change an ID after that point.
> >
> > 1. Would there be any downside to such a policy?
> 
> Only if somebody builds the database without the "backwards" file,
> which lists the backwards-compatibility names.  The default is to
> include "backwards", as it includes very common IDs like US/Pacific.
> I'd be surprised (but not astonished) if someone omitted it.

I wonder if it would be a good idea to separate the old-style names
(US/Eastern, etc.) from compatibility versions of old Area/Location names.
It seems like FreeBSD and similar systems would in general want to have the
latter even if not the former.

--

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Re: Question on id stability

Jonathan Lennox <lennox <at> cnr.cs.columbia.edu> writes:

> I wonder if it would be a good idea to separate the old-style names
> (US/Eastern, etc.) from compatibility versions of old Area/Location names.
> It seems like FreeBSD and similar systems would in general want to have the
> latter even if not the former.

It's not entirely clear which is which for Australian names like
"Australia/Canberra".  However, here's a little awk script that
you can apply to the "backwards" file if you want just the
old Area/Location names.

BEGIN {
  area["Africa"] = 1; area["America"] = 1; area["Antarctica"] = 1
  area["Arctic"] = 1; area["Asia"] = 1; area["Atlantic"] = 1
  area["Etc"] = 1; area["Europe"] = 1
  area["Indian"] = 1; area["Pacific"] = 1
  # Australia is special; it's old-style names (I think).
}
/^Link/ && area[substr($3, 1, index($3, "/") - 1)]