- tz - lists.iana.org

Two more weeks with DST in Uruguay
by Steffen Thorsen March 12, 2005

March 12, 2005

Uruguay's DST was scheduled to end on Sunday, 2005-03-13, but in order to save energy; it was postponed two weeks, until 2005-03-27, at either 3 or 2 in the morning (I'm not quite sure because the automatic translation tools don't give a very good translation). The official announcement is available here (Spanish): http://www.presidencia.gub.uy/_Web/noticias/2005/03/2005031005.htm Some background information is available here (also Spanish): http://www.cncs.com.uy/?tc=nt&nt=2543 Best regards, Steffen

2 1

FW: Who ist the maintainer of tzdata?
by Olson, Arthur David (NIH/NCI) March 12, 2005

March 12, 2005

Since sending this message Alois Treindl has joined the time zone mailing list. --ado -----Original Message----- From: Alois Treindl [mailto:alois@astro.ch] Sent: Thursday, March 10, 2005 5:24 AM To: tz(a)lecserver.nci.nih.gov Subject: Who ist the maintainer of tzdata? I have a project to expand tzdata. Summarizing shortly, the rough idea is to - add boundary descriptions to each area with a different timezone history so that with given coordinates it can automatically be determined to which timezone history 'table' a given location belongs. I am aware that many non-trivial issues of geo-information processing arise with such a goal. - add more details for the complicated timezone history of some countries, e.g. Canada, where other sources have identified more than 250 regions with different timezone history, whereas current tzdata has only 15 regions. I am aware that this is a large project which will require resources measured in man-years. I may be in a position to contribute/sponsor such resources. I would like to communicate with the current maintainers of tzdata about these ideas, and about the best approach for such an expansion. My motivation background is the field of serious astrology, where reliable timezone history information is an essential requirement. tzdata is doing an excellent job to provide reliable information for current timzones, but it lacks sadly (and understandably, given the complexity of the problem) in historical detail. Alois Treindl

3 2

proposed tz change for Uruguay (plus tz-link update)
by Paul Eggert March 11, 2005

March 11, 2005

Here's a proposed change to the tz database to reflect the news from Uruguay. The tz rules for Uruguay are currently incorrect for time stamps past this Sunday. Thanks to Steffen Thorsen for the info about Uruguay. Also, this patch adds a link to VelaTerra's recent offer of free licenses to tz database contributors. =================================================================== RCS file: RCS/southamerica,v retrieving revision 2005.5 retrieving revision 2005.5.0.2 diff -pu -r2005.5 -r2005.5.0.2 --- southamerica 2005/02/07 21:19:42 2005.5 +++ southamerica 2005/03/11 23:31:13 2005.5.0.2 @@ -1063,8 +1063,12 @@ 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 - +Rule Uruguay 2004 only - Sep 19 0:00 1:00 S +# From Steffen Thorsen (2005-03-11): +# Uruguay's DST was scheduled to end on Sunday, 2005-03-13, but in order to +# save energy ... it was postponed two weeks.... +# http://www.presidencia.gub.uy/_Web/noticias/2005/03/2005031005.htm +Rule Uruguay 2005 only - Mar 27 2: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/tz-link.htm,v retrieving revision 2005.6 retrieving revision 2005.6.0.2 diff -pu -r2005.6 -r2005.6.0.2 --- tz-link.htm 2005/03/01 13:44:11 2005.6 +++ tz-link.htm 2005/03/11 23:35:28 2005.6.0.2 @@ -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="2005-01-11" /> +<meta name="DC.Date" content="2005-03-11" /> <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" /> @@ -224,8 +224,10 @@ Java-specific format.</li> href="http://www1.tip.nl/~t876506/AboutTimeZonesHC.html">HyperCard time zones calculator</a> is a HyperCard stack.</li> <li><a -href="http://www.veladesigngroup.com/velaterra.html">VelaTerra</a> is -a Mac OS X program.</li> +href="http://www.veladg.com/velaterra.html">VelaTerra</a> is +a Mac OS X program. Its developers +<a href="http://www.veladg.com/tzoffer.html">offer free +licenses</a> to <code>tz</code> contributors.</li> <li><a href="http://www.cimmyt.org/timezone/">World Time Explorer</a> is a Microsoft Windows program.</li>

1 0

RE: Is more detailed timezone history desired?
by Olson, Arthur David (NIH/NCI) March 10, 2005

March 10, 2005

Top priorities would be: 1. Ensure that the format of the time zone source files is adequate to represent historical changes. 2. Document changes since 1970-01-01 (the POSIX epoch). --ado -----Original Message----- From: Alois Treindl [mailto:alois@astro.ch] Sent: Thursday, March 10, 2005 4:54 PM To: tz(a)lecserver.nci.nih.gov Subject: Is more detailed timezone history desired? regarding my project to extend the details of timezone history in tzdata, a first question: Is it desirable, in the eyes of current tzdata maintainers, to add such extensions?

5 4

Time zone: the next generation
by Olson, Arthur David (NIH/NCI) March 10, 2005

March 10, 2005

Time zone package: the next generation Over the last year we've done as much as possible, within the existing time zone package framework, to cope with systems with 64-bit time_t values. But the zone information compiler (zic) still produces binary files with 32-bit transition time values. Something's gotta give. As long as we're making changes, it's best to do as much as possible (to avoid the need for further change down the road). I've listed problems, approaches, and questions below. Much of this material is related to general matters of time rather than specific matters of time zones; my apologies. PROBLEMS * Future transition times/past transition times The binary files produced by zic record transition times as 32-bit values; times after the 2038 (or before 1901) cannot be represented. (The future limit can be extended to 2106 by treating the values as unsigned, but if that's done times before 1970 cannot be represented.) * Transitions in Israel Israel now goes back to standard time in the fall on the Saturday before Yom Kippur; there's no convenient way to represent this in the input to zic. * Julian-Gregorian transition Signed 32-bit time_t values can only represent years going back to 1901; this means that for most areas of the world the Gregorian calendar is in effect for all times representable by such a time_t. Signed 64-bit time_t values have a far greater range; the range always includes all instants when areas switched from Julian to Gregorian. There's no provision for handling the switch in the time zone package. (The transition happens at different times in different places; in addition to handling the jump over a number of days, there's also the matter of figuring out whether a year ending in 00 is a leap year in a particular place.) * Year zero Some year numbering schemes skip over the year zero; others do not. There's no provision for specifying whether or not to skip in the time zone package. * Early years of Julian calendar Leap years were inserted every three (rather than four) years early in the life of the Julian calendar; some leap years were skipped later to make up for this. Month lengths (and names) were also in flux for a while. Documentation of the glitches is shaky; there's no way to reflect what documentation we do have. * Pre-Julian calendars The time zone package cannot handle information about the Roman Republic calendar or any of its predecessors. * Non-Julian-Gregorian calendars The time zone package cannot handle information about non-Julian-Gregorian time schemes (Mayan, Martian, and so on). * Big Bang/Big Crunch Signed 64-bit time_t values have enough range to go back to theorized time of the Big Bang origin of the universe and thus back to the start of time itself. Some folks might want to fold all instants "before" the Big Bang in to that instant. At the other end, advocates of the Big Crunch theory might want to treat time_t values greater than the predicted Crunch instant as if they were the Crunch instant. There's no way to do such pegging in the time zone package. * Creation/Apocalypse Some folks might want to peg past times at a predicted time of Creation and peg future times at a predicted Apocalypse. APPROACHES * Do nothing Since things don't get sticky until at least 2037, it's possible to wait (at least for a while) before taking action. * Tweak the binary file format At the least this would involve widening stored transition times beyond 32 bits. It might also be necessary to widen offsets as a way of coping with Julian/Gregorian shifts and year zero skips. * Abandon binary files We're now operating on the "terminfo" model in which human-readable descriptions are converted to binary form (with some precomputation done) for use by programs. We could shift to the earlier "termcap" model, simply copying files such as "asia" and "northamerica" to a public directory and interpreting them at run time. This eliminates the need to change binary file formats (since such files disappear); there might still be a need to change the source file format if we wanted to do things such as handle Julian/Gregorian transitions. Responsibly taking this approach might involve learning why the termcap-to-terminfo transition occurred, and whether the reasons are still applicable in today's computing environment. * Preprocess We could change "zic" so that for each zone it outputs a file with only those Rule and Zone lines required for the zone; there could be some simplification of the output (such as expressing all times in UTC) to ease interpretation. Again there would be run-time interpretation, but the job would be scaled down (by pre-identification of relevant data) and simplified. * Change zic's output to another format We could take the vzic route of reading the existing source files and producing VZONEINFO format output. We might want to extend the VZONEINFO format (for example, to handle leap seconds). We might want to produce output in some other existing format, or in a newly designed format. QUESTIONS * Do we handle Julian/Gregorian transitions? * Do we allow control of skipping the year zero? * Do we handle early-Julian leap year variations? * Do we handle pegging of far-past and far-future times? * For each new of the above: * What default assumption should be used in zic and in run-time software? * Can the assumption be overridden in a time zone source file? If so, how? * Can the assumption be overridden using an environment variable? If so, how? * Can the assumption be overridden with function calls? If so, how? * Do we simplify handling of events tied to non-Gregorian-calendar-related events (such as Yom Kippur)? * Do we handle pre-Julian or non-Julian-Gregorian time schemes? * When Sherman types... %horton TZ=Europe/Rome wayback March 15 -44 ...will he and Mr. Peabody witness an assassination? So...before discussing any of the above in detail...are the problems, approaches, and questions above correct and complete? If not, what should be changed? --ado

13 22

Timezone converstion
by Rajesh Vargheese March 10, 2005

March 10, 2005

Hello, I was trying to evaluate tz libs for timezone usage for my application. My need: Given a region id [ex. "America/New_York"] and a UTC time, i want to get the offset i need to get the time for that region. I also need the Day light savings to be accounted. Can I use the libtz library to do this. Please let me if there are any location where I can get some sample code in C/C++ to do this. I tried to get the old archive so that I can find an answer, but its erroring out. Thanks in advance, Rajesh

1 0

FW: Time zone: the next generation
by Olson, Arthur David (NIH/NCI) March 10, 2005

March 10, 2005

Since sending this message, Alois has joined the time zone mailing list. --ado -----Original Message----- From: Alois Treindl [mailto:alois@astro.ch] Sent: Thursday, March 10, 2005 5:54 AM To: Olson, Arthur David (NIH/NCI) Cc: Tz (tz(a)elsie.nci.nih.gov) Subject: Re: Time zone: the next generation On Thu, 3 Mar 2005, Olson, Arthur David (NIH/NCI) wrote: > QUESTIONS > > * Do we handle Julian/Gregorian transitions? Yes, but with an override feature in the API. One of the problems is that many history texts contain converted calendar dates. For the consistency of a particular history book, biography etc, authors have a tendency to convert all calendar data contained in them into one system, even if at the given date and location a different calendar might have applied. If a related calendar/timezone database makes strict assumptions about which calendar applied for a given date, then new problems are introduced. > * Do we allow control of skipping the year zero? Both styles of year counting have a name. The one with year zero is called 'astronomical year counting style' and it indicates years BC with negative year numbers. The one without year zero is called 'historical year counting style' and it indicates years BC with the suffix BC or BCE or something similar, but never with a plus/minus sign. I think the documentation should be clear, but the API needs only to support one style. > * Do we handle pegging of far-past and far-future times? Aside from calendar system changes, no time zone data are known for dates before the 1800s. There is an issue whether true solar time or mean solar time was used for the recording of a particular historical event. But I do not see how tzdata should be able to answer this question. E.g. when J.W.Goethe mentions in one of his works that he was born at noon on 28 August 1749 (greg. calendar) in Frankfurt: Does he mean true solar time (as indicated by a sun dial) or mean solar time (as measured by an astronomical clock in an observatory)? tzdata cannot know this, and should not claim that it knows. There was no clear transition between true solar time and mean solar time reckoning, before the formal introduction of timezone standards in the 19th century. Alois Treindl

1 0

Who ist the maintainer of tzdata?
by Alois Treindl March 10, 2005

March 10, 2005

I have a project to expand tzdata. Summarizing shortly, the rough idea is to - add boundary descriptions to each area with a different timezone history so that with given coordinates it can automatically be determined to which timezone history 'table' a given location belongs. I am aware that many non-trivial issues of geo-information processing arise with such a goal. - add more details for the complicated timezone history of some countries, e.g. Canada, where other sources have identified more than 250 regions with different timezone history, whereas current tzdata has only 15 regions. I am aware that this is a large project which will require resources measured in man-years. I may be in a position to contribute/sponsor such resources. I would like to communicate with the current maintainers of tzdata about these ideas, and about the best approach for such an expansion. My motivation background is the field of serious astrology, where reliable timezone history information is an essential requirement. tzdata is doing an excellent job to provide reliable information for current timzones, but it lacks sadly (and understandably, given the complexity of the problem) in historical detail. Alois Treindl

1 0

RE: Time zone: the next generation (future transitions)
by Olson, Arthur David (NIH/NCI) March 8, 2005

March 8, 2005

The Gregorian calendar cycles every 400 years: January 1 fell on a [Saturday] in 2000, and will do so again in 2400. In a traditional-zic approach, we could store 400 (or more) years worth of future transitions; stuff beyond that could be handled at run time. For example, a localtime call would, for far future times: cast out 400 years worth of seconds at a time to get to the near future (remembering how many years worth of seconds had been cast out); convert the resulting time_t value; and add the cast-off number of years to the resulting time_t value. We'd of course need to check at run time to verify that this was the right approach. --ado

1 0

Olson database name ambiguity
by Tom Yandell March 7, 2005

March 7, 2005

Hi Apologies for cross posting this. I think that this is a problem in the data in the Olson database, but as it is a binary format it is difficult to verify this. I have come across this problem using the DateTime perl module (version 0.28) whose data is generated from the Olson database. The problem that I am experiencing is that the short name for timezones for 'Europe/London' up until 1996 were either 'GMT' or 'BST' (depending if daylight saving changes were in effect). From 1996 the name for the timezone is the rather less precise 'GMT/BST' regardless of whether daylight saving changes are in effect or not. I have attached a script that demonstrates this, and its output. Regards, Tom

2 1