- tz - lists.iana.org

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

Re: FW: Time zone: the next generation
by kennykb＠crd.ge.com March 4, 2005

March 4, 2005

Clive Feather posts some interesting historical observations about the calendar, which I suppressed from my original posting because I thought that they'd drown the readers in irrelevant detail -- a one-line summary, in my arrogant opinion, is "we don't want to go there." -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

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

March 4, 2005

Kevin Kenny is on the time zone mailing list, but at a different address than that shown below. --ado -----Original Message----- From: kennykb(a)crd.ge.com [mailto:kennykb@crd.ge.com] Sent: Thursday, March 03, 2005 3:22 PM To: Tz (tz(a)elsie.nci.nih.gov) Subject: Re: Time zone: the next generation I've done a good bit of similar code for the Tcl programming language (see http://www.tcl.tk/cgi-bin/tct/tip/173 for details). The implementation there can handle the proleptic Julian calendar, with a defined change date. There are a number of caveats worth mentioning: - Prior to the Julian conversion, different locales had different rules for when the number of the year changed. In and before 1752 in Great Britain, for instance, the number of the year changed on 25 March; 1-24 March belonged to the previous year! With the adoption of the Gregorian calendar, the change was universally 1 January. (For this reason, you'll sometimes see eighteenth-century dates as O.S. ("Old Style") or N.S. ("New Style") when the year would otherwise be ambiguous. I decided for Tcl not to bother with any kind of localized rule for year numbering in those circumstances; it was too much of a mess. - As you correctly observe, leap years were observed irregularly in Rome in Republican and early Imperial times. In fact, they were so irregularly observed that it was occasionally necessary to intercalate entire months. Again, I decided with Tcl not to bother. - It appears unnecessary to control skipping the year zero. I have not encountered any locale where there is such a beast; in all cases, it appears that the year 1 B.C.E. is followed by the year 1 C.E. - I use a message catalog (the same catalog in which I hold localised month names) to hold a locale's Julian conversion date, and then select the catalog according to LC_TIME. Tcl's ordinary message catalog functionality can be used to change the date. - I have not yet troubled to implement anything but Gregorian (or hybrid Julian-Gregorian) calendars. I did a limited amount of localization to handle the Japanese civil calendar, but only for dates after the Meiji restoration (when it's Gregorian, except that years number from the start of an emperor's reign). Incidentally, Tcl's counterpart to zic (which uses the same input format as zic) simply uses 64-bit counts of seconds for its transition times. Also, it doesn't track leap seconds, since Tcl's model of time is Markus Kuhn's "smoothed universal time" (http://www.cl.cam.ac.uk/~mgk25/uts.txt) in which leap seconds are handled by changing the length of a second by 1 part in 1000 until Tcl's clock is back in sync with UTC. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

4 3

Re: Time zone: the next generation
by kennykb＠crd.ge.com March 3, 2005

March 3, 2005

I've done a good bit of similar code for the Tcl programming language (see http://www.tcl.tk/cgi-bin/tct/tip/173 for details). The implementation there can handle the proleptic Julian calendar, with a defined change date. There are a number of caveats worth mentioning: - Prior to the Julian conversion, different locales had different rules for when the number of the year changed. In and before 1752 in Great Britain, for instance, the number of the year changed on 25 March; 1-24 March belonged to the previous year! With the adoption of the Gregorian calendar, the change was universally 1 January. (For this reason, you'll sometimes see eighteenth-century dates as O.S. ("Old Style") or N.S. ("New Style") when the year would otherwise be ambiguous. I decided for Tcl not to bother with any kind of localized rule for year numbering in those circumstances; it was too much of a mess. - As you correctly observe, leap years were observed irregularly in Rome in Republican and early Imperial times. In fact, they were so irregularly observed that it was occasionally necessary to intercalate entire months. Again, I decided with Tcl not to bother. - It appears unnecessary to control skipping the year zero. I have not encountered any locale where there is such a beast; in all cases, it appears that the year 1 B.C.E. is followed by the year 1 C.E. - I use a message catalog (the same catalog in which I hold localised month names) to hold a locale's Julian conversion date, and then select the catalog according to LC_TIME. Tcl's ordinary message catalog functionality can be used to change the date. - I have not yet troubled to implement anything but Gregorian (or hybrid Julian-Gregorian) calendars. I did a limited amount of localization to handle the Japanese civil calendar, but only for dates after the Meiji restoration (when it's Gregorian, except that years number from the start of an emperor's reign). Incidentally, Tcl's counterpart to zic (which uses the same input format as zic) simply uses 64-bit counts of seconds for its transition times. Also, it doesn't track leap seconds, since Tcl's model of time is Markus Kuhn's "smoothed universal time" (http://www.cl.cam.ac.uk/~mgk25/uts.txt) in which leap seconds are handled by changing the length of a second by 1 part in 1000 until Tcl's clock is back in sync with UTC. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development kennykb(a)crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA

1 0

Timezone Dates for Israel [2005 and beyond]
by Ephraim Silverberg March 2, 2005

March 2, 2005

>From now on, Daylight Saving Time in the State of Israel will commence at 02:00 a.m. on the first Friday before April 2nd and will last until 02:00 a.m. on the first Sunday before the Jewish fast of Yom Kippur. The proposed law amendment can be viewed (for those who read Hebrew) at: ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2005+beyond.ps Note that although the wording of the law is not final, its intent is -- a free translation of the text would read: Every year, between the last Friday of the month of March, at 02:00, and the last Sunday before the tenth of [the Hebrew month of] Tishrei [i.e. the fast of Yom Kippur], at 02:00, the time in Israel will be made one hour earlier so that it will precede Coordinated Universal Time by three hours; in a year that the first of April falls on a Friday, the time will be made earlier, in the manner mentioned, in that year, on this day at 02:00. Attached to this message are the context diffs for "tzdata2005e/asia". I have also update the ZIC entry Emacs generator at: ftp://ftp.cs.huji.ac.il/pub/tz/software/dst-israel.el although it does not use year-range short-hand notation and produces explicit dates for each year. ___________________________________________________________________________ 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

2 2

Tzcode2005f.tar.gz and tzdata2005f.tar.gz
by Olson, Arthur David (NIH/NCI) March 1, 2005

March 1, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005f.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005f.tar.gz ...are now available; these include the data and documentation changes circulated on the time zone mailing list last week by Paul Eggert. --ado

1 0

FW: Question about: TWiki.org Service: Date and Time Gateway
by Olson, Arthur David (NIH/NCI) Feb. 23, 2005

Feb. 23, 2005

Neither Peter nor Krystian is on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Peter Thoeny [mailto:peter.thoeny@attglobal.net] Sent: Sunday, February 13, 2005 6:23 PM To: krystian(a)mindspring.com; tz(a)lecserver.nci.nih.gov Subject: Re: Question about: TWiki.org Service: Date and Time Gateway Dear Krystian and tz team, The program on TWiki.org takes the data from the Olson tz database, http://www.twinsun.com/tz/tz-link.htm I am not sure I can explain the +/- GMT question, someone from the Olson tz database team is probably better in that. More info on GMT at http://en.wikipedia.org/wiki/GMT Info on timezones at http://wwp.greenwichmeantime.com/info/timezone.htm Interstingly, above site shows GMT times in reverse to the Olson database! E.g. for me in California, the Olson database tells me I am in Etc/GMT+8, and greenwichmeantime.com tells me I am GMT-8. Regards, Confused Peter krystian(a)mindspring.com wrote: > > This question pertains to the data within: > > TWiki.org Service: Date and Time Gateway > http://twiki.org/cgi-bin/xtra/tzdate > > Which I believe is under a revision by your penmanship. > > Q. Are the GMT offsets mixed in this website? When I think of GMT-5 I > think of Eastern Standard Time, however your site lists GMT-5 as where > I always think GMT+5 is. > > > Greenwich Mean Time: (GMT/UCT/UTC/Universal/Zulu; positive numbers > > count hours west of GMT > > What is the cause of having positive numbers count west of GMT? Aren't > positive numbers, by definition, to be east of GMT? (like GMT+5 is add > 5 hours to the time at GMT?) > > I've seen lots of confusion about this on the web and I don't > understand why this is so. I have always thought GMT-5 was Eastern > Standard Time, not some time in the European longitudes. > > Can you please speculate on this? I'm also trying to find the > difference between UTC and GMT (as I've read they are the same but not > exactly). Maybe this is how they differ. > > I'm terribly confused. Please offer an explanation to your readers in > the form of a link or direct them to such a place. > > Regards, > Roland Krystian Alberciak. -- * Peter Thoeny Peter(a)Thoeny.com * Is your team already TWiki enabled? http://TWiki.org * This e-mail is: (_) public (x) ask first (_) private

5 5

Re: Question about: TWiki.org Service: Date and Time Gateway
by Peter Thoeny Feb. 13, 2005

Feb. 13, 2005

Dear Krystian and tz team, The program on TWiki.org takes the data from the Olson tz database, http://www.twinsun.com/tz/tz-link.htm I am not sure I can explain the +/- GMT question, someone from the Olson tz database team is probably better in that. More info on GMT at http://en.wikipedia.org/wiki/GMT Info on timezones at http://wwp.greenwichmeantime.com/info/timezone.htm Interstingly, above site shows GMT times in reverse to the Olson database! E.g. for me in California, the Olson database tells me I am in Etc/GMT+8, and greenwichmeantime.com tells me I am GMT-8. Regards, Confused Peter krystian(a)mindspring.com wrote: > > This question pertains to the data within: > > TWiki.org Service: Date and Time Gateway > http://twiki.org/cgi-bin/xtra/tzdate > > Which I believe is under a revision by your penmanship. > > Q. Are the GMT offsets mixed in this website? When I think of GMT-5 I think > of Eastern Standard Time, however your site lists GMT-5 as where I always > think GMT+5 is. > > > Greenwich Mean Time: (GMT/UCT/UTC/Universal/Zulu; > > positive numbers count hours west of GMT > > What is the cause of having positive numbers count west of GMT? Aren't > positive numbers, by definition, to be east of GMT? (like GMT+5 is add 5 > hours to the time at GMT?) > > I've seen lots of confusion about this on the web and I don't understand why > this is so. I have always thought GMT-5 was Eastern Standard Time, not some > time in the European longitudes. > > Can you please speculate on this? I'm also trying to find the difference > between UTC and GMT (as I've read they are the same but not exactly). Maybe > this is how they differ. > > I'm terribly confused. Please offer an explanation to your readers in the > form of a link or direct them to such a place. > > Regards, > Roland Krystian Alberciak. -- * Peter Thoeny Peter(a)Thoeny.com * Is your team already TWiki enabled? http://TWiki.org * This e-mail is: (_) public (x) ask first (_) private

1 0

Tzcode2005e.tar.gz and tzdata2005e.tar.gz
by Olson, Arthur David (NIH/NCI) Feb. 10, 2005

Feb. 10, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005e.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005e.tar.gz ...are now available; these incorporate the changes circulated last week on the time zone mailing list. My fond hope is the above code is stable for now; it's time for a design phase to figure out what else (if anything) to do to cope with 64-bit time_t values. Details to follow. --ado

1 0

Re: Israel 2005 and Beyond -- Proposed Timezone Dates
by Paul Eggert Feb. 8, 2005

Feb. 8, 2005

Ephraim Silverberg <ephraim(a)cse.huji.ac.il> writes: > emacs -batch -l dst-israel.el > > ... If the law passes, I'll put the script in the Israel TZ ftp depository. Thanks for doing that! A couple of minor comments. First, the existing database uses "Apr<tab>25" and "Apr<tab><space>9" rather than "Apr<space>25" and "Apr<space><space>9". Also, it'd be a bit handier to input a range of dates rather than a single date. I used your program to write the following draft patch. I don't think this should go into the tz database just yet (Israeli politics being what they are) but I thought you might like to see the draft. Thanks again. --- asia 2004/10/11 18:44:51 2004.5 +++ asia 2004/12/22 23:00:21 @@ -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-12-22): # According to the Office of the Secretary General of the Ministry of # Interior, there is NO set rule for Daylight-Savings/Standard time changes. @@ -690,13 +690,13 @@ Rule Zion 1995 only - Sep 3 0:00 0 S # time, Haim Ramon. The official announcement regarding 1996-1998 # (with the dates for 1997-1998 no longer being relevant) can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/1996-1998.ramon.ps.gz # # The dates for 1997-1998 were altered by his successor, Rabbi Eli Suissa. # # The official announcements for the years 1997-1999 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/YYYY.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/YYYY.ps.gz # # where YYYY is the relevant year. @@ -716,12 +716,12 @@ Rule Zion 1999 only - Sep 3 2:00 0 S # # The official announcement for the start date of 2000 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/2000-start.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2000-start.ps.gz # # The official announcement for the end date of 2000 and the dates # for the years 2001-2004 can be viewed at: # -# ftp://ftp.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2000-2004.ps.gz # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Zion 2000 only - Apr 14 2:00 1:00 D @@ -735,52 +735,97 @@ 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 -# 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. +# Yesterday, the Knesset Interior Committee passed a proposed (originally +# in March 2004) change to the Time Setting Law that would make the dates +# for DST from 2005 and beyond so that DST starts on the night _after_ the +# first night of the Passover holiday at midnight until midnight of the +# Saturday night _before_ the fast of Yom Kippur. +# +# Those who can read Hebrew can view the proposal at: +# +# ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2005+.ps +# +# The proposal still has to be passed by the Knesset (three readings) for +# it to become law.... + +# From Paul Eggert (2004-12-22): +# For now, guess that the rules proposed on 2004-12-20 will be adopted. +# This is quite possibly wrong, but it is more likely than no DST at all. +# I used Ed Reingold's cal-hebrew in GNU Emacs 21.3, along with code +# written by Ephraim Silverberg, to generate this list. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Zion 2005 max - Apr 1 1:00 1:00 D -Rule Zion 2005 max - Oct 1 1:00 0 S +Rule Zion 2005 only - Apr 25 0:00 1:00 D +Rule Zion 2005 only - Oct 9 0:00 0 S +Rule Zion 2006 only - Apr 14 0:00 1:00 D +Rule Zion 2006 only - Oct 1 0:00 0 S +Rule Zion 2007 only - Apr 4 0:00 1:00 D +Rule Zion 2007 only - Sep 16 0:00 0 S +Rule Zion 2008 only - Apr 21 0:00 1:00 D +Rule Zion 2008 only - Oct 5 0:00 0 S +Rule Zion 2009 only - Apr 10 0:00 1:00 D +Rule Zion 2009 only - Sep 27 0:00 0 S +Rule Zion 2010 only - Mar 31 0:00 1:00 D +Rule Zion 2010 only - Sep 12 0:00 0 S +Rule Zion 2011 only - Apr 20 0:00 1:00 D +Rule Zion 2011 only - Oct 2 0:00 0 S +Rule Zion 2012 only - Apr 8 0:00 1:00 D +Rule Zion 2012 only - Sep 23 0:00 0 S +Rule Zion 2013 only - Mar 27 0:00 1:00 D +Rule Zion 2013 only - Sep 8 0:00 0 S +Rule Zion 2014 only - Apr 16 0:00 1:00 D +Rule Zion 2014 only - Sep 28 0:00 0 S +Rule Zion 2015 only - Apr 5 0:00 1:00 D +Rule Zion 2015 only - Sep 20 0:00 0 S +Rule Zion 2016 only - Apr 24 0:00 1:00 D +Rule Zion 2016 only - Oct 9 0:00 0 S +Rule Zion 2017 only - Apr 12 0:00 1:00 D +Rule Zion 2017 only - Sep 24 0:00 0 S +Rule Zion 2018 only - Apr 1 0:00 1:00 D +Rule Zion 2018 only - Sep 16 0:00 0 S +Rule Zion 2019 only - Apr 21 0:00 1:00 D +Rule Zion 2019 only - Oct 6 0:00 0 S +Rule Zion 2020 only - Apr 10 0:00 1:00 D +Rule Zion 2020 only - Sep 27 0:00 0 S +Rule Zion 2021 only - Mar 29 0:00 1:00 D +Rule Zion 2021 only - Sep 12 0:00 0 S +Rule Zion 2022 only - Apr 17 0:00 1:00 D +Rule Zion 2022 only - Oct 2 0:00 0 S +Rule Zion 2023 only - Apr 7 0:00 1:00 D +Rule Zion 2023 only - Sep 24 0:00 0 S +Rule Zion 2024 only - Apr 24 0:00 1:00 D +Rule Zion 2024 only - Oct 6 0:00 0 S +Rule Zion 2025 only - Apr 14 0:00 1:00 D +Rule Zion 2025 only - Sep 28 0:00 0 S +Rule Zion 2026 only - Apr 3 0:00 1:00 D +Rule Zion 2026 only - Sep 20 0:00 0 S +Rule Zion 2027 only - Apr 23 0:00 1:00 D +Rule Zion 2027 only - Oct 10 0:00 0 S +Rule Zion 2028 only - Apr 12 0:00 1:00 D +Rule Zion 2028 only - Sep 24 0:00 0 S +Rule Zion 2029 only - Apr 1 0:00 1:00 D +Rule Zion 2029 only - Sep 16 0:00 0 S +Rule Zion 2030 only - Apr 19 0:00 1:00 D +Rule Zion 2030 only - Oct 6 0:00 0 S +Rule Zion 2031 only - Apr 9 0:00 1:00 D +Rule Zion 2031 only - Sep 21 0:00 0 S +Rule Zion 2032 only - Mar 28 0:00 1:00 D +Rule Zion 2032 only - Sep 12 0:00 0 S +Rule Zion 2033 only - Apr 15 0:00 1:00 D +Rule Zion 2033 only - Oct 2 0:00 0 S +Rule Zion 2034 only - Apr 5 0:00 1:00 D +Rule Zion 2034 only - Sep 17 0:00 0 S +Rule Zion 2035 only - Apr 25 0:00 1:00 D +Rule Zion 2035 only - Oct 7 0:00 0 S +Rule Zion 2036 only - Apr 13 0:00 1:00 D +Rule Zion 2036 only - Sep 28 0:00 0 S +Rule Zion 2037 only - Apr 1 0:00 1:00 D +Rule Zion 2037 only - Sep 13 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:56 - LMT 1880 2:20:40 - JMT 1918 # Jerusalem Mean Time? 2:00 Zion I%sT -# From Ephraim Silverberg (2003-03-23): -# -# Minister of Interior Poraz has announced that he will respect the law -# passed in July 2000 (proposed at the time jointly by himself and -# then-MK David Azulai [Shas]) fixing the dates for 2000-2004. Hence, -# the dates for 2003 and 2004 remain unchanged.... -# -# As far as 2005 and beyond, no dates have been set. However, the -# minister has mentioned that he wishes to propose to move Israel's -# timezone in 2005 from GMT+2 to GMT+3 and upon that have DST during -# the summer months (i.e. GMT+4). However, no legislation in this -# direction is expected until the latter part of 2004 which is a long -# time off in terms of Israeli politics. - -# (2004-09-20): -# 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]. - -# (2004-09-26): -# Even though the draft law for the above did pass the Ministerial Committee -# for Legislative Matters three months ago, it was voted down in today's -# Cabinet meeting. The current suggestion is to keep the current timezone at -# UTC+0200 but have an extended period of Daylight Saving Time (UTC+0300) from -# the beginning of Passover holiday in the spring to after the Tabernacle -# holiday in the fall (i.e. the dates of which are governed by the Hebrew -# calendar but this means at least 184 days of DST). However, this is only a -# suggestion that was raised in today's cabinet meeting and has not yet been -# drafted. - ###############################################################################

2 2

FW: IANA time zone registration - proposal
by Olson, Arthur David (NIH/NCI) Feb. 7, 2005

Feb. 7, 2005

Doug Royer is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Doug Royer [mailto:Doug@Royer.com] Sent: Monday, January 17, 2005 2:12 PM To: tz(a)lecserver.nci.nih.gov Subject: IANA time zone registration - proposal [This was sent to some IETF mailing lists by me and someone suggested I send it to this list also] This is REV -00 of the proposal - comments welcome. Data in in it can easily updated. (Like the TZ names updated to latest copy of data) ---------------------------------------------------- A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF. A copy can be found at: http://inet-consulting.com/draft-royer-timezone-registry-00.txt And an HTML version: http://inet-consulting.com/draft-royer-timezone-registry-00.html I am adding the POLYGON property targeted for the -01 version that has an ADD/DELETE parameter to allow for the optional inclusion of latitude/longitude geographic areas to be included that include (add) and exclude (delete) areas from the time zone geographic region (again from the CALSCH mailing list discussions). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug(a)Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards

7 10

Re: proposed minor changes
by Olson, Arthur David (NIH/NCI) Feb. 7, 2005

Feb. 7, 2005

Ken Pizzini reviewed the proposed changes sent out last week and pointed out a change I failed to note in the summary: the setlocale calls in zic.c and zdump.c have been changed to use the LC_ALL parameter rather than the LC_MESSAGES parameter. (This based on earlier electronic mail claiming that setting only LC_MESSAGES rather than LC_ALL can lead to problems.) As suggested by Paul Eggert, the "diff -b" output appears below. --ado diff -b -c old/date.c new/date.c *** old/date.c Mon Jan 31 09:20:47 2005 --- new/date.c Mon Jan 31 14:06:49 2005 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.40"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.41"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ *************** *** 664,670 **** cp = value; switch (dotp - cp) { default: ! wildinput(_("time"), value, _("main part is wrong length")); case 12: if (!dousg) { cent = ATOI2(cp); --- 664,671 ---- cp = value; switch (dotp - cp) { default: ! wildinput(_("time"), value, ! _("main part is wrong length")); case 12: if (!dousg) { cent = ATOI2(cp); diff -b -c old/private.h new/private.h *** old/private.h Mon Jan 31 09:19:08 2005 --- new/private.h Mon Jan 31 14:06:49 2005 *************** *** 91,103 **** #include "time.h" #include "stdlib.h" ! #if HAVE_GETTEXT - 0 #include "libintl.h" ! #endif /* HAVE_GETTEXT - 0 */ ! #if HAVE_SYS_WAIT_H - 0 #include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ ! #endif /* HAVE_SYS_WAIT_H - 0 */ #ifndef WIFEXITED #define WIFEXITED(status) (((status) & 0xff) == 0) --- 91,103 ---- #include "time.h" #include "stdlib.h" ! #if HAVE_GETTEXT #include "libintl.h" ! #endif /* HAVE_GETTEXT */ ! #if HAVE_SYS_WAIT_H #include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ ! #endif /* HAVE_SYS_WAIT_H */ #ifndef WIFEXITED #define WIFEXITED(status) (((status) & 0xff) == 0) *************** *** 106,116 **** #define WEXITSTATUS(status) (((status) >> 8) & 0xff) #endif /* !defined WEXITSTATUS */ ! #if HAVE_UNISTD_H - 0 #include "unistd.h" /* for F_OK and R_OK */ ! #endif /* HAVE_UNISTD_H - 0 */ ! #if !(HAVE_UNISTD_H - 0) #ifndef F_OK #define F_OK 0 #endif /* !defined F_OK */ --- 106,116 ---- #define WEXITSTATUS(status) (((status) >> 8) & 0xff) #endif /* !defined WEXITSTATUS */ ! #if HAVE_UNISTD_H #include "unistd.h" /* for F_OK and R_OK */ ! #endif /* HAVE_UNISTD_H */ ! #if !HAVE_UNISTD_H #ifndef F_OK #define F_OK 0 #endif /* !defined F_OK */ *************** *** 117,123 **** #ifndef R_OK #define R_OK 4 #endif /* !defined R_OK */ ! #endif /* !(HAVE_UNISTD_H - 0) */ /* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ #define is_digit(c) ((unsigned)(c) - '0' <= 9) --- 117,123 ---- #ifndef R_OK #define R_OK 4 #endif /* !defined R_OK */ ! #endif /* !HAVE_UNISTD_H */ /* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ #define is_digit(c) ((unsigned)(c) - '0' <= 9) *************** *** 216,222 **** void * irealloc P((void * pointer, int size)); void icfree P((char * pointer)); void ifree P((char * pointer)); ! char * scheck P((const char *string, const char *format)); /* ** Finally, some convenience items. --- 216,222 ---- void * irealloc P((void * pointer, int size)); void icfree P((char * pointer)); void ifree P((char * pointer)); ! char * scheck P((const char *string, char *format)); /* ** Finally, some convenience items. *************** *** 255,261 **** ** add one more for a minus sign if the type is signed. */ #define INT_STRLEN_MAXIMUM(type) \ ! ((TYPE_BIT(type) - TYPE_SIGNED(type)) * 302 / 1000 + 1 + TYPE_SIGNED(type)) #endif /* !defined INT_STRLEN_MAXIMUM */ /* --- 255,262 ---- ** add one more for a minus sign if the type is signed. */ #define INT_STRLEN_MAXIMUM(type) \ ! ((TYPE_BIT(type) - TYPE_SIGNED(type)) * 302 / 1000 + \ ! 1 + TYPE_SIGNED(type)) #endif /* !defined INT_STRLEN_MAXIMUM */ /* *************** *** 289,299 **** */ #ifndef _ ! #if HAVE_GETTEXT - 0 #define _(msgid) gettext(msgid) ! #else /* !(HAVE_GETTEXT - 0) */ #define _(msgid) msgid ! #endif /* !(HAVE_GETTEXT - 0) */ #endif /* !defined _ */ #ifndef TZ_DOMAIN --- 290,300 ---- */ #ifndef _ ! #if HAVE_GETTEXT #define _(msgid) gettext(msgid) ! #else /* !HAVE_GETTEXT */ #define _(msgid) msgid ! #endif /* !HAVE_GETTEXT */ #endif /* !defined _ */ #ifndef TZ_DOMAIN diff -b -c old/scheck.c new/scheck.c *** old/scheck.c Mon Jan 31 09:20:47 2005 --- new/scheck.c Mon Jan 31 14:06:49 2005 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)scheck.c 8.15"; #endif /* !defined lint */ #endif /* !defined NOID */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)scheck.c 8.16"; #endif /* !defined lint */ #endif /* !defined NOID */ *************** *** 11,17 **** char * scheck(string, format) const char * const string; ! const char * const format; { register char * fbuf; register const char * fp; --- 11,17 ---- char * scheck(string, format) const char * const string; ! char * const format; { register char * fbuf; register const char * fp; diff -b -c old/strftime.c new/strftime.c *** old/strftime.c Mon Jan 31 09:20:47 2005 --- new/strftime.c Mon Jan 31 14:06:50 2005 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.74"; /* ** 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.75"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 108,114 **** static char * _add P((const char *, char *, const char *)); static char * _conv P((int, const char *, char *, const char *)); ! static char * _fmt P((const char *, const struct tm *, char *, const char *, int *)); static char * _yconv P((int, int, int, int, char *, const char *)); extern char * tzname[]; --- 108,115 ---- static char * _add P((const char *, char *, const char *)); static char * _conv P((int, const char *, char *, const char *)); ! static char * _fmt P((const char *, const struct tm *, char *, const char *, ! int *)); static char * _yconv P((int, int, int, int, char *, const char *)); extern char * tzname[]; diff -b -c old/tzfile.h new/tzfile.h *** old/tzfile.h Mon Jan 31 09:19:08 2005 --- new/tzfile.h Mon Jan 31 14:06:49 2005 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char tzfilehid[] = "@(#)tzfile.h 7.16"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char tzfilehid[] = "@(#)tzfile.h 7.17"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 172,197 **** #define isleap_sum(a, b) isleap((a) % 400 + (b) % 400) - #ifndef USG - - /* - ** Use of the underscored variants may cause problems if you move your code to - ** certain System-V-based systems; for maximum portability, use the - ** underscore-free variants. The underscored variants are provided for - ** backward compatibility only; they may disappear from future versions of - ** this file. - */ - - #define SECS_PER_MIN SECSPERMIN - #define MINS_PER_HOUR MINSPERHOUR - #define HOURS_PER_DAY HOURSPERDAY - #define DAYS_PER_WEEK DAYSPERWEEK - #define DAYS_PER_NYEAR DAYSPERNYEAR - #define DAYS_PER_LYEAR DAYSPERLYEAR - #define SECS_PER_HOUR SECSPERHOUR - #define SECS_PER_DAY SECSPERDAY - #define MONS_PER_YEAR MONSPERYEAR - - #endif /* !defined USG */ - #endif /* !defined TZFILE_H */ --- 172,175 ---- diff -b -c old/zdump.c new/zdump.c *** old/zdump.c Mon Jan 31 09:20:47 2005 --- new/zdump.c Mon Jan 31 14:20:42 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.61"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.63"; /* ** This code has been made independent of the rest of the time *************** *** 215,221 **** INITIALIZE(cutlotime); INITIALIZE(cuthitime); #if HAVE_GETTEXT ! (void) setlocale(LC_MESSAGES, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined TEXTDOMAINDIR */ --- 215,221 ---- INITIALIZE(cutlotime); INITIALIZE(cuthitime); #if HAVE_GETTEXT ! (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined TEXTDOMAINDIR */ diff -b -c old/zic.c new/zic.c *** old/zic.c Mon Jan 31 09:20:47 2005 --- new/zic.c Mon Jan 31 14:20:42 2005 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zic.c 7.120"; /* ** Regardless of the type of time_t, we do our work using this type. --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.122"; /* ** Regardless of the type of time_t, we do our work using this type. *************** *** 138,146 **** static void writezone P((const char * name)); static int yearistype P((int year, const char * type)); ! #if !(HAVE_STRERROR - 0) static char * strerror P((int)); ! #endif /* !(HAVE_STRERROR - 0) */ static int charcnt; static int errors; --- 138,146 ---- static void writezone P((const char * name)); static int yearistype P((int year, const char * type)); ! #if !HAVE_STRERROR static char * strerror P((int)); ! #endif /* !HAVE_STRERROR */ static int charcnt; static int errors; *************** *** 380,386 **** ** Error handling. */ ! #if !(HAVE_STRERROR - 0) static char * strerror(errnum) int errnum; --- 380,386 ---- ** Error handling. */ ! #if !HAVE_STRERROR static char * strerror(errnum) int errnum; *************** *** 391,397 **** return (errnum > 0 && errnum <= sys_nerr) ? sys_errlist[errnum] : _("Unknown system error"); } ! #endif /* !(HAVE_STRERROR - 0) */ static void eats(name, num, rname, rnum) --- 391,397 ---- return (errnum > 0 && errnum <= sys_nerr) ? sys_errlist[errnum] : _("Unknown system error"); } ! #endif /* !HAVE_STRERROR */ static void eats(name, num, rname, rnum) *************** *** 448,454 **** static void usage P((void)) { ! (void) fprintf(stderr, _("%s: usage is %s [ --version ] [ -s ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), progname, progname); (void) exit(EXIT_FAILURE); } --- 448,456 ---- static void usage P((void)) { ! (void) fprintf(stderr, _("%s: usage is %s \ ! [ --version ] [ -s ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ ! \t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), progname, progname); (void) exit(EXIT_FAILURE); } *************** *** 472,484 **** #ifdef unix (void) umask(umask(S_IWGRP | S_IWOTH) | (S_IWGRP | S_IWOTH)); #endif /* defined unix */ ! #if HAVE_GETTEXT - 0 ! (void) setlocale(LC_MESSAGES, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined TEXTDOMAINDIR */ (void) textdomain(TZ_DOMAIN); ! #endif /* HAVE_GETTEXT - 0 */ progname = argv[0]; for (i = 1; i < argc; ++i) if (strcmp(argv[i], "--version") == 0) { --- 474,486 ---- #ifdef unix (void) umask(umask(S_IWGRP | S_IWOTH) | (S_IWGRP | S_IWOTH)); #endif /* defined unix */ ! #if HAVE_GETTEXT ! (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR (void) bindtextdomain(TZ_DOMAIN, TZ_DOMAINDIR); #endif /* defined TEXTDOMAINDIR */ (void) textdomain(TZ_DOMAIN); ! #endif /* HAVE_GETTEXT */ progname = argv[0]; for (i = 1; i < argc; ++i) if (strcmp(argv[i], "--version") == 0) { *************** *** 631,652 **** (void) exit(EXIT_FAILURE); result = link(fromname, toname); ! #if (HAVE_SYMLINK - 0) if (result != 0 && access(fromname, F_OK) == 0 && !itsdir(fromname)) { const char *s = tofile; register char * symlinkcontents = NULL; - while ((s = strchr(s+1, '/')) != NULL) - symlinkcontents = ecatalloc(symlinkcontents, "../"); - symlinkcontents = ecatalloc(symlinkcontents, fromfile); ! result = symlink(symlinkcontents, toname); if (result == 0) warning(_("hard link failed, symbolic link used")); ifree(symlinkcontents); } ! #endif if (result != 0) { const char *e = strerror(errno); --- 633,659 ---- (void) exit(EXIT_FAILURE); result = link(fromname, toname); ! #if HAVE_SYMLINK if (result != 0 && access(fromname, F_OK) == 0 && !itsdir(fromname)) { const char *s = tofile; register char * symlinkcontents = NULL; ! while ((s = strchr(s+1, '/')) != NULL) ! symlinkcontents = ! ecatalloc(symlinkcontents, ! "../"); ! symlinkcontents = ! ecatalloc(symlinkcontents, ! fromfile); ! result = symlink(symlinkcontents, ! toname); if (result == 0) warning(_("hard link failed, symbolic link used")); ifree(symlinkcontents); } ! #endif /* HAVE_SYMLINK */ if (result != 0) { const char *e = strerror(errno); *************** *** 1107,1113 **** zones[nzones - 1].z_untiltime > min_time && zones[nzones - 1].z_untiltime < max_time && zones[nzones - 1].z_untiltime >= z.z_untiltime) { ! error(_("Zone continuation line end time is not after end time of previous line")); return FALSE; } } --- 1114,1122 ---- zones[nzones - 1].z_untiltime > min_time && zones[nzones - 1].z_untiltime < max_time && zones[nzones - 1].z_untiltime >= z.z_untiltime) { ! error(_( ! "Zone continuation line end time is not after end time of previous line" ! )); return FALSE; } } *************** *** 1141,1147 **** cp = fields[LP_YEAR]; if (sscanf(cp, scheck(cp, "%d"), &year) != 1) { /* ! * Leapin' Lizards! */ error(_("invalid leaping year")); return; --- 1150,1156 ---- cp = fields[LP_YEAR]; if (sscanf(cp, scheck(cp, "%d"), &year) != 1) { /* ! ** Leapin' Lizards! */ error(_("invalid leaping year")); return; *************** *** 1211,1217 **** return; } if ((lp = byword(fields[LP_ROLL], leap_types)) == NULL) { ! error(_("illegal Rolling/Stationary field on Leap line")); return; } leapadd(tadd(t, tod), positive, lp->l_value, count); --- 1220,1228 ---- return; } if ((lp = byword(fields[LP_ROLL], leap_types)) == NULL) { ! error(_( ! "illegal Rolling/Stationary field on Leap line" ! )); return; } leapadd(tadd(t, tod), positive, lp->l_value, count); *************** *** 1473,1485 **** while (fromi < timecnt && attypes[fromi].type == 0) ++fromi; /* handled by default rule */ for ( ; fromi < timecnt; ++fromi) { ! if (toi != 0 ! && ((attypes[fromi].at ! + gmtoffs[attypes[toi - 1].type]) ! <= (attypes[toi - 1].at ! + gmtoffs[toi == 1 ? 0 : attypes[toi - 2].type]))) { ! attypes[toi - 1].type = attypes[fromi].type; continue; } if (toi == 0 || --- 1484,1495 ---- while (fromi < timecnt && attypes[fromi].type == 0) ++fromi; /* handled by default rule */ for ( ; fromi < timecnt; ++fromi) { ! if (toi != 0 && ((attypes[fromi].at + ! gmtoffs[attypes[toi - 1].type]) <= ! (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 : attypes[toi - 2].type]))) { ! attypes[toi - 1].type = ! attypes[fromi].type; continue; } if (toi == 0 || *************** *** 1526,1532 **** convert(eitol(typecnt), tzh.tzh_typecnt); convert(eitol(charcnt), tzh.tzh_charcnt); (void) strncpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); ! #define DO(field) (void) fwrite((void *) tzh.field, (size_t) sizeof tzh.field, (size_t) 1, fp) DO(tzh_magic); DO(tzh_reserved); DO(tzh_ttisgmtcnt); --- 1536,1543 ---- convert(eitol(typecnt), tzh.tzh_typecnt); convert(eitol(charcnt), tzh.tzh_charcnt); (void) strncpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); ! #define DO(field) (void) fwrite((void *) tzh.field, \ ! (size_t) sizeof tzh.field, (size_t) 1, fp) DO(tzh_magic); DO(tzh_reserved); DO(tzh_ttisgmtcnt); *************** *** 1746,1757 **** } if (*startbuf == '\0' && startoff == oadd(zp->z_gmtoff, ! stdoff)) { ! doabbr(startbuf, zp->z_format, rp->r_abbrvar, ! rp->r_stdoff != 0); } - } eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); doabbr(buf, zp->z_format, rp->r_abbrvar, --- 1757,1769 ---- } if (*startbuf == '\0' && startoff == oadd(zp->z_gmtoff, ! stdoff)) ! doabbr(startbuf, ! zp->z_format, rp->r_abbrvar, ! rp->r_stdoff != ! 0); } eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); doabbr(buf, zp->z_format, rp->r_abbrvar, *************** *** 2041,2047 **** else while ((*dp = *cp++) != '"') if (*dp != '\0') ++dp; ! else error(_("Odd number of quotation marks")); } while (*cp != '\0' && *cp != '#' && (!isascii(*cp) || !isspace((unsigned char) *cp))); if (isascii(*cp) && isspace((unsigned char) *cp)) --- 2053,2061 ---- else while ((*dp = *cp++) != '"') if (*dp != '\0') ++dp; ! else error(_( ! "Odd number of quotation marks" ! )); } while (*cp != '\0' && *cp != '#' && (!isascii(*cp) || !isspace((unsigned char) *cp))); if (isascii(*cp) && isspace((unsigned char) *cp)) *************** *** 2162,2168 **** } if (i < 0 || i >= len_months[isleap(y)][m]) { if (noise) ! warning(_("rule goes past start/end of month--will not work with pre-2004 versions of zic")); } } if (dayoff < 0 && !TYPE_SIGNED(zic_t)) --- 2176,2183 ---- } if (i < 0 || i >= len_months[isleap(y)][m]) { if (noise) ! warning(_("rule goes past start/end of month--\ ! will not work with pre-2004 versions of zic")); } } if (dayoff < 0 && !TYPE_SIGNED(zic_t))

1 0

Re: Re[2]: Corrections to timezone database
by Mark Davis Feb. 7, 2005

Feb. 7, 2005

> But I insist that there should be an entry "Asia/Beijing" first. > "Beijing Time" is represented by Shanghai, which is a unacceptable > situation. As far as we are concerned, the tzid is simply an internal tag, marking a region of the Earth that has the same timezone behavior, all the way back to the point in time where timezones started to be used instead of solar time. The name for that tzid may vary by language, and it should be the most customary form for that language (or even country). It is a bit like arguing that CN should not be the official ISO 3166 country code for China, because it is not an acronym for the Chinese name for the country. The common name is divorced from the particular combination of letters used for the code. The code is an internal tag, which should be represented with an appropriate string for whatever the user's language is. The main purpose of the code is that it be well-defined and unique. If Shanghai and Beijing ever had different timezone behavior, that would warrant having a different tzid; otherwise it doesn't. ‎Mark ----- Original Message ----- From: "Funda Wang" <fundawang(a)gmail.com> To: "Mark Davis" <mark.davis(a)jtcsv.com> Cc: "Paul Eggert" <eggert(a)CS.UCLA.EDU>; "Tz (tz(a)elsie.nci.nih.gov)" <tz(a)lecserver.nci.nih.gov> Sent: Friday, February 04, 2005 14:20 Subject: Re[2]: Corrections to timezone database > Mark> I do want to call people's attention to the CLDR project work on timezone > Mark> identifiers (http://unicode.org/cldr/) > Sounds interesting. But should I join this project as an individual? > > Mark> (All of this can be overridden by specific localizations for generic, > Mark> standard, or daylight names. So if the equivalent of "Beijing Time" is what > Mark> is customary in Chinese, we could use that.) > I probably don't understand what you say. Do you mean that you would do > following modification?: > Asia/Shanghai => 北京时间 > > If all other countries will be using the country name, it would be fine > that we use China(中国). > > But I insist that there should be an entry "Asia/Beijing" first. > "Beijing Time" is represented by Shanghai, which is a unacceptable > situation. >

2 3

Re: Re[4]: Corrections to timezone database
by Mark Davis Feb. 5, 2005

Feb. 5, 2005

> But why there are Harbin and other cities? Those cities are using the > same timezone UTC+8, isn't it? The others are distinguished because at some time in the past, there was some point at which they differed in time. So in this case, Asia/Shanghai differed from Asia/Harbin on 1980‑04‑30 15:29Z (8.5 vs. 8). See http://oss.software.ibm.com/cvs/icu/~checkout~/locale/docs/design/formattin… (now slightly out of date). ‎Mark ----- Original Message ----- From: "Funda Wang" <fundawang(a)gmail.com> To: "Mark Davis" <mark.davis(a)jtcsv.com> Cc: "Paul Eggert" <eggert(a)CS.UCLA.EDU>; "Tz (tz(a)elsie.nci.nih.gov)" <tz(a)lecserver.nci.nih.gov> Sent: Saturday, February 05, 2005 15:09 Subject: Re[4]: Corrections to timezone database > Mark> The name for that tzid may vary by language, and it should be the most > Mark> customary form for that language (or even country). > Sure. Then, "Beijing Time" is the most commonly used in China, no matter > how crowded Shanghai is. > > Mark> It is a bit like arguing that CN should not be the official ISO 3166 country > Mark> code for China, because it is not an acronym for the Chinese name for the > Mark> country. > But we have zh_CN as an acceptable choices. > > Mark> If Shanghai and Beijing ever had different timezone behavior, that would > Mark> warrant having a different tzid; otherwise it doesn't. > But why there are Harbin and other cities? Those cities are using the > same timezone UTC+8, isn't it? AFAIK, Beijing is more crowded than > Harbin or Chongqing. And, although Urmuqi is located in UTC+7 timezone, > the official timezone of Xinjiang is UTC+8 - Beijing Time. > > >

1 0

Re: Corrections to timezone database
by Mark Davis Feb. 5, 2005

Feb. 5, 2005

I'll post this to the list, in case others are curious. >From http://unicode.org/cldr/ you can find out about the membership and participation. Anyone can file a bug against the database. See Filing Bug Reports on that page. ‎Mark ----- Original Message ----- From: "walter harms" <wharms(a)bfs.de> To: "Mark Davis" <mark.davis(a)jtcsv.com> Sent: Friday, February 04, 2005 09:07 Subject: Re: Corrections to timezone database > I mark, > who collects remarks about the translation ? > > I have some Problems since the 'official Name' and the common name differ: > e.g.: > belarus/weisrussland (even the pages: > http://www.auswaertiges-amt.de/www/de/laenderinfos/laender/laender_ausgabe_… > mix these) > > > Côte d’Ivoire: Elfenbeinküste > Suriname: -> sometimes: Surinam > > re, > walter > > > > Mark Davis wrote: > > I do want to call people's attention to the CLDR project work on timezone > > identifiers (http://unicode.org/cldr/) > > > > We are in the process of gathering localization data for this coming > > release. We have gathered some data for the locales {locale identifiers: ar > > cs da de en es fi fr hu it ja nb nl pl pt pt_PT ru sv tr zh zh_Hant}, and > > are working on fleshing those out and adding more (we're not done yet!). See > > http://unicode.org/cldr/data/dropbox/timezones/. > > > > For example, the following shows the current translations using the data we > > have (for German): > > > > http://unicode.org/cldr/data/dropbox/timezones/de_current.html > > > > And the following shows a checklist for translators (note: in many cases > > those don't *need* translation, since they are the same as the default > > names.) > > > > http://unicode.org/cldr/data/dropbox/timezones/de_to_localize.xml > > > > ===== > > > > The mechanism we use for the generic (wall time) tzid is: > > > > If a country has a single zone, we use the country name. Example (from > > Chinese simplified): > > > > Europe/Brussels => 比利时 > > > > Otherwise we use the last field of the TZID, followed by the country name in > > parens. Example: > > > > Australia/Melbourne => 墨尔本 (澳大利亚) > > > > We are going to be adding additional information where one zones in > > *certain* multi-zone countries will just use the country name. Example, we > > have currently: > > > > Asia/Shanghai => 上海 (中国) > > Asia/Kashgar => 喀什葛尔 (中国) > > > > Once we have that data, we'll generate: > > > > Asia/Shanghai => 中国 > > Asia/Kashgar => 喀什葛尔 (中国) > > > > (All of this can be overridden by specific localizations for generic, > > standard, or daylight names. So if the equivalent of "Beijing Time" is what > > is customary in Chinese, we could use that.) > > > > ‎Mark > > > > ----- Original Message ----- > > From: "Paul Eggert" <eggert(a)CS.UCLA.EDU> > > To: "Funda Wang" <fundawang(a)gmail.com> > > Cc: "Tz (tz(a)elsie.nci.nih.gov)" <tz(a)lecserver.nci.nih.gov> > > Sent: Friday, February 04, 2005 00:08 > > Subject: Re: Corrections to timezone database > > > > > > > >>Funda Wang <fundawang(a)gmail.com> writes: > >> > >> > >>>In fact, we do not have an official abbreviation for "The Time of > >>>Beijing", as we do not use English :) > >> > >>OK, in that case we should probably stick with "CST", as it > >>abbreviates the most commonly used English phrase for the time in > >>China. > >> > >>The tz database is an English database, by and large. For example, it > >>uses the abbreviation "CET" for Central European Time even though most > >>residents of Central Europe use other abbrevations like "MEZ". We > >>don't currently have the resources to localize all the abbreviations, > >>so we stick with English ones. If and when the database is localized, > >>we will transliterate "CST" in China to the appropriate Chinese > >>characters (e.g., the characters for "The Time of Beijing"). > >> > >> > >>>the main reason that there should be a "Beijing" is that we call > >>>UTC+8 as "The Time of Beijing". > >> > >>There is longstanding precedent in the tz database for decoupling tz > >>zone labels from informal time zone names. For example, the tz label > >>"Europe/London" denotes local time in England, even though the people > >>in England call their local time "Greenwich Mean Time". The case of > >>Beijing is somewhat similar. > >> > >> > > > > > > >

1 0

Re: Corrections to timezone database
by Paul Eggert Feb. 4, 2005

Feb. 4, 2005

Funda Wang <fundawang(a)gmail.com> writes: > In fact, we do not have an official abbreviation for "The Time of > Beijing", as we do not use English :) OK, in that case we should probably stick with "CST", as it abbreviates the most commonly used English phrase for the time in China. The tz database is an English database, by and large. For example, it uses the abbreviation "CET" for Central European Time even though most residents of Central Europe use other abbrevations like "MEZ". We don't currently have the resources to localize all the abbreviations, so we stick with English ones. If and when the database is localized, we will transliterate "CST" in China to the appropriate Chinese characters (e.g., the characters for "The Time of Beijing"). > the main reason that there should be a "Beijing" is that we call > UTC+8 as "The Time of Beijing". There is longstanding precedent in the tz database for decoupling tz zone labels from informal time zone names. For example, the tz label "Europe/London" denotes local time in England, even though the people in England call their local time "Greenwich Mean Time". The case of Beijing is somewhat similar.

2 1

FW: Re[2]: Corrections to timezone database
by Olson, Arthur David (NIH/NCI) Feb. 4, 2005

Feb. 4, 2005

Funda Wang is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Funda Wang [mailto:fundawang@gmail.com] Sent: Thursday, February 03, 2005 1:14 PM To: Olson, Arthur David (NIH/NCI) Subject: Re[2]: Corrections to timezone database Olson,> The normal procedure is to use the most populous city in the time zone; thus Olson,> Shanghai rather than Beijing (and New York rather than Washington). Thanks for your clear explanation. The reason why Shanghai is the most populouse city in China is that there is no surburb around Shanghai. For other municipalities such as Beijing, Tianjin and Chongqing, there are a large area of surburb around them, while the population density of these surbub areas is far more lower than downtown. Anyway, I do think there should be a "Beijing" in timezone list. The timezone we Chinese are using is UTC+8, which is called "The Time of Beijing(TTB)" in China, rather "China Standard Time(CST)", no matter what number of population density do beijing have. Even in the western part of China, say Urumqi, they are using TTB while the actual geographic timezone it locates is UTC+7. And, you may know, someone may take it as political issue the lack of Beijing.

2 1