- tz - lists.iana.org

IERS Message No. 141: New IERS Rapid Service/Prediction Center web site
by central_bureau＠iers.org Jan. 14, 2009

Jan. 14, 2009

************************************************************************ IERS Message No. 141 January 14, 2009 ************************************************************************ New IERS Rapid Service/Prediction Center web site Dear Colleagues, We would like to inform you that the IERS Rapid Service/Prediction Center's web site will be moving from http://maia.usno.navy.mil to http://www.usno.navy.mil/USNO/earth-orientation on 15 January 2009. Note that until the changeover date, the new web site can be found at http://199.211.133.90/USNO/earth-orientation. In addition to the change in address, the style of the web site has been changed to bring it into compliance with an institution-wide format. It is expected that attempting to access the old web site should result in a redirect to the new web site. We have been assured that this change in our web presence will in no way impact our e-mail or our ftp capabilities, i.e. ftp maia.usno.navy.mil will not be impacted. We would appreciate hearing any comments you have regarding the new web site. If you notice any unusual behavior, please let us know. Regards, William Wooden Director, IERS Rapid Service/Prediction Center ************************************************************************ IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ************************************************************************

1 0

Meaning of 'goforward' flag ?
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

I think I understand how the ats array is extrapolated to dates beyond its end. The Gregorian calendar repeats every 400 years, so any rules based on weekdays and day of month numbers will have results that repeat. So, if the date is beyond the end of the array, subtract the smallest multiple of 400 years that produces a date that is within the array, and use the ttis entry that points to. This assumes that the last set of rules in force were used to generate at least 400 years of entries in ats. Is that correct? But, the code to set goforward based on the ats array decides TRUE if there exists an entry that is equivalent to the last entry but exactly 400 years earlier. That does not guarantee that the last 400 years was meant to be repeated. I'm guessing that zic fills out a whole cycle of the last set of rules in force and then one more ats entry to serve as a cue for tzload, or that the POSIX string could generate more than one complete cycle (i.e. MAX_TIMES was large enough). But simply setting a flag in the header, or noting that the POSIX string existed and could fill out 400 years, would be clearer and avoid hidden meanings. As it is, zic would have to be careful to avoid letting that cue occur by happenstance. If you don't worry about that happening, why worry about 'goback', which never occurs in the actual data? Any newly minted time zone would inherit the past from the region is split off from, so it never will. --John

1 0

code review issue re t outside of ats array's range
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

In 'localsub', If t is before the first entry in ats, and goback is not set, then it uses the first non-DST entry in ats. But, if t is after the last entry in ats and goforward is not net, then it uses the last entry in ats, regardless of whether it is a DST or standard time entry. Is that intentional? ... thinking ... time passes ... I think it's an error either way - if the ats table ends with a seasonal time change and it isn't flagged as goforward, it should be an error that the table was declared too small. It stays in DST forever and if it's flagged as DST that means it was supposed to be a temporary adjustment to the Zone definition. --John

1 0

Timezone code question
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

The zic program goes to the trouble of generating a POSIX string for "the future" that is the last thing in the data file. The library code turns that into two more ttis records. Why not just store two more ttis records in the file in the first place? What does 'ttis' stand for? What about 'ats'?

1 0

Leap Second Data
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

Why is the leap second data associated with each data file? Shouldn't it be the same everywhere? --John

1 0

FW: time zone library
by Olson, Arthur David (NIH/NCI) [E] Jan. 13, 2009

Jan. 13, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 06, 2009 7:10 To: tz(a)lecserver.nci.nih.gov Subject: time zone library I downloaded the timezone library, and in adapting it to my needs I've been figuring out how it works. I have a few questions, and also (hopefully) a contribution. First, my contribution. Regarding /* ** Adapted from code provided by Robert Elz, who writes: ** The "best" way to do mktime I think is based on an idea of Bob ** Kridle's (so its said...) from a long time ago. ** It does a binary search of the time_t space. Since time_t's are ** just 32 bits, its a max of 32 iterations (even at 64 bits it ** would still be very reasonable). */ I'm using 64-bit time_t values, and find that it usually takes 62 to 64 iterations. Basically, it is always worst case. I tried using a rough guess for the initial hi and low: lo = ((yourtm.tm_year-70) * 365i64 + yourtm.tm_mon * 28) * SecondsPerDay; hi = ((yourtm.tm_year-70) * 366i64 + (yourtm.tm_mon+1)*31) * SecondsPerDay; when the resulting time_t would be positive, and it completes in 20 to 23 iterations. I punted on the negative case, but a very similar calculation would work. When tm_year < 70, I just used the smallest value I care about for lo, and 0 for hi. That gives me worst case 35 iterations, because I'm only supporting values back to 1752 CE, not the full range of a 64-bit number, which would be 21 times longer than the age of the universe. Now for my first question. TZ_MAX_TIMES is 1200, and that is exactly the length of the arrays for state::ats and state::types. I suppose it is noting every time change, e.g. DST adjustments twice a year for 600 years? There is no need to store anything before the first reported time in the configuration files, as it simply uses the first entry for anything older (no DST in pre-history); it seems to have code for dealing with dates beyond the end of the table. Does it extrapolate the current DST rule in the future? I'd like to cut off the table at a more reasonable date for my application. Where is that table populated? Is it when the data file is loaded, or in zic when it is created? My second question concerns leap seconds. It appears that the leap second data is associated with every zone file. Why isn't it simply the same for everything, and global? --John

4 5

Australian timezone abbreviations
by Ted Percival Jan. 12, 2009

Jan. 12, 2009

Paul Eggert wrote: > I'd like to hear more from Australian correspondents on this before > thinking about specific changes, though. +1 me for changing to AEST, AEDT and so on. I encourage you to read through a relatively recent discussion about this. I straw-polled our Unix users' group's mailing list: http://lists.humbug.org.au/archives/general/2008-April/thread.html#26929 . If you'll excuse the deviation to a discussion of whether various places should have daylight saving time, you'll see a preference for AEST: I count 6 for and 1 possibly against. Eric Ulevik wrote: > ABC NewsRadio have been referring to 'Eastern Standard Time' and > 'Eastern Summer Time'. "Australian" is presumed for an Australian radio broadcast; for computer use there is no regional context. At any rate, the discussion should focus on the *abbreviations* rather than the full names because only the abbreviations are specified by the timezone database. I'm not convinced that searching the web for "EST" is a valid survey, particularly as it is a common abbreviation for "estimate" or "established". There are also websites such as Flickr that use EST but there is evidence that this is simply a result of using the timezone database: a feedback loop. I wonder to what extent the timezone database is seen as an authority for what people use. -- Ted Percival http://tedp.id.au/tzdata-au/

1 0

"Military" time zones
by Paul Eggert Jan. 10, 2009

Jan. 10, 2009

msb(a)vex.net (Mark Brader; please reply accordingly) writes: > As you would know, there is a system of "military" time zone > designations where zones are identified by a single letter: > http://www.timeanddate.com/library/abbreviations/timezones/military/ > gives letter equivalents for zones from -12 = Y to +12 = M. > > I was having an email conversation with Russ Rowlett, who maintains > the units-of-measurement site at <http://www.unc.edu/~rowlett/units/>, > and we were wondering whether these single-letter designations are > actually still used in practice -- and, if so, how time zones above > +12 or not on integer hours are represented. Is there an official > reference for current practice on this anywhere? Yes, please see the Combined Communications-Electronics Board general communication instructions, dated 2007 <http://www.jcs.mil/j6/cceb/acps/acp121/ACP121H.pdf>. These are authoritative for the armed forces of Australia, Canada, NZ, the UK, and the US. Briefly: "N" is also used for UTC+13, "to provide for a ship in zone -12 keeping Daylight Saving Time". There's no official provision for UTC+14, but I presume that'd be "O". For DST, use the corresponding next letter (e.g., the eastern-US "R" becomes "Q" during DST.) As for non-integer hours, the instructions simply say: "For time midway between zones, both letters are used."

2 1

Time Zone y Chihuahua Mexico
by Marco Antonio Bravo Grajeda Jan. 8, 2009

Jan. 8, 2009

Chihuahua has a different time zone than the center of Mexico, please correct this.

1 0

timezone code - re-entrancy issue
by John Dlugosz Jan. 7, 2009

Jan. 7, 2009

At the bottom of localsub, tzname[tmp->tm_isdst] = &sp->chars[ttisp->tt_abbrind]; I think this is to update the tzname string to the last time zone abbr. actually used in to produce the tm values. It is not re-entrant. This is called even by localtime_r, which may be changing the values even as another thread (who called plain localtime) is reading it. It also changes all the time as the "binary search" is being done by mktime. That violates the "behaves as if never called" rule, and putting it in a subroutine doesn't help there. Am I missing something? --John

1 0

time zone library
by John Dlugosz Jan. 7, 2009

Jan. 7, 2009

I downloaded the timezone library, and in adapting it to my needs I've been figuring out how it works. I have a few questions, and also (hopefully) a contribution. First, my contribution. Regarding /* ** Adapted from code provided by Robert Elz, who writes: ** The "best" way to do mktime I think is based on an idea of Bob ** Kridle's (so its said...) from a long time ago. ** It does a binary search of the time_t space. Since time_t's are ** just 32 bits, its a max of 32 iterations (even at 64 bits it ** would still be very reasonable). */ I'm using 64-bit time_t values, and find that it usually takes 62 to 64 iterations. Basically, it is always worst case. I tried using a rough guess for the initial hi and low: lo = ((yourtm.tm_year-70) * 365i64 + yourtm.tm_mon * 28) * SecondsPerDay; hi = ((yourtm.tm_year-70) * 366i64 + (yourtm.tm_mon+1)*31) * SecondsPerDay; when the resulting time_t would be positive, and it completes in 20 to 23 iterations. I punted on the negative case, but a very similar calculation would work. When tm_year < 70, I just used the smallest value I care about for lo, and 0 for hi. That gives me worst case 35 iterations, because I'm only supporting values back to 1752 CE, not the full range of a 64-bit number, which would be 21 times longer than the age of the universe. Now for my first question. TZ_MAX_TIMES is 1200, and that is exactly the length of the arrays for state::ats and state::types. I suppose it is noting every time change, e.g. DST adjustments twice a year for 600 years? There is no need to store anything before the first reported time in the configuration files, as it simply uses the first entry for anything older (no DST in pre-history); it seems to have code for dealing with dates beyond the end of the table. Does it extrapolate the current DST rule in the future? I'd like to cut off the table at a more reasonable date for my application. Where is that table populated? Is it when the data file is loaded, or in zic when it is created? My second question concerns leap seconds. It appears that the leap second data is associated with every zone file. Why isn't it simply the same for everything, and global? --John

1 0

FW: Oops - forgot to make sure the URL was clear
by Olson, Arthur David (NIH/NCI) [E] Jan. 5, 2009

Jan. 5, 2009

I'm forwarding this message from Dave Thewlis, who is not on the time zone mailing list (at least not at the address below). Those of you who are on the list, please direct replies appropriately. --ado From: Dave Thewlis [mailto:Dave.Thewlis@calconnect.org] Sent: Monday, January 05, 2009 5:33 To: Olson, Arthur David (NIH/NCI) [E] Subject: Oops - forgot to make sure the URL was clear Dear Arthur David, Thanks you very much for posting the invitation. However the URL about the workshop didn't come through clearly, so if you would, could you please add the following post to the TZ list: URL for the CalConnect Timezone Workshop Please see http://www.calconnect.org/timezoneworkshop.shtml for more information and to register. Thanks! Dave Thewlis -- Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis(a)calconnect.org

1 0

Patch to support --help
by Joseph S. Myers Jan. 2, 2009

Jan. 2, 2009

The tools zdump and zic support the GNU-standard --version option (output version information to stdout and exit successfully), but not the associated --help option (output usage and bug reporting information to stdout and exit successfully). This patch adds such support. tzselect supports neither option, so this patch adds support for both options to it. diff -ru tzcode.orig/tzselect.ksh tzcode/tzselect.ksh --- tzcode.orig/tzselect.ksh 2008-09-10 02:33:17.000000000 +0000 +++ tzcode/tzselect.ksh 2009-01-02 16:55:45.000000000 +0000 @@ -1,6 +1,6 @@ #! /bin/ksh -# '@(#)tzselect.ksh 8.1' +VERSION='@(#)tzselect.ksh 8.1' # Ask the user about the time zone, and output the resulting TZ value to stdout. # Interact with the user via stderr and stdin. @@ -45,6 +45,21 @@ exit 1 } +if [ "$1" = "--help" ]; then + cat <<EOF +Usage: tzselect +Select a time zone interactively. + +Report bugs to tz(a)elsie.nci.nih.gov. +EOF + exit 0 +elif [ "$1" = "--version" ]; then + cat <<EOF +tzselect $VERSION +EOF + exit 0 +fi + # Make sure the tables are readable. TZ_COUNTRY_TABLE=$TZDIR/iso3166.tab TZ_ZONE_TABLE=$TZDIR/zone.tab diff -ru tzcode.orig/zdump.c tzcode/zdump.c --- tzcode.orig/zdump.c 2008-09-10 02:33:24.000000000 +0000 +++ tzcode/zdump.c 2009-01-02 16:56:59.000000000 +0000 @@ -230,6 +230,17 @@ warned = TRUE; } +static void +usage(const char *progname, FILE *stream, int status) +{ + (void) fprintf(stream, +_("%s: usage is %s [ --version ] [ --help ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n\ +\n\ +Report bugs to tz(a)elsie.nci.nih.gov.\n"), + progname, progname); + exit(status); +} + int main(argc, argv) int argc; @@ -266,6 +277,8 @@ if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(progname, stdout, EXIT_SUCCESS); } vflag = 0; cutarg = NULL; @@ -275,10 +288,7 @@ else cutarg = optarg; if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { - (void) fprintf(stderr, -_("%s: usage is %s [ --version ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n"), - progname, progname); - exit(EXIT_FAILURE); + usage(progname, stderr, EXIT_FAILURE); } if (vflag) { if (cutarg != NULL) { diff -ru tzcode.orig/zic.c tzcode/zic.c --- tzcode.orig/zic.c 2008-09-10 02:33:18.000000000 +0000 +++ tzcode/zic.c 2009-01-02 16:57:40.000000000 +0000 @@ -156,7 +156,7 @@ const struct zone * zp, int ntzones); static void setboundaries(void); static zic_t tadd(zic_t t1, long t2); -static void usage(void); +static void usage(FILE *stream, int status); static void writezone(const char * name, const char * string); static int yearistype(int year, const char * type); @@ -454,13 +454,15 @@ } static void -usage(void) +usage(FILE *stream, int status) { - (void) fprintf(stderr, _("%s: usage is %s \ -[ --version ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ -\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), - progname, progname); - exit(EXIT_FAILURE); + (void) fprintf(stream, _("%s: usage is %s \ +[ --version ] [ --help ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ +\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n\ +\n\ +Report bugs to tz(a)elsie.nci.nih.gov.\n"), + progname, progname); + exit(status); } static const char * psxrules; @@ -498,11 +500,13 @@ if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(stdout, EXIT_SUCCESS); } while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF && c != -1) switch (c) { default: - usage(); + usage(stderr, EXIT_FAILURE); case 'd': if (directory == NULL) directory = optarg; @@ -561,7 +565,7 @@ break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) - usage(); /* usage message by request */ + usage(stderr, EXIT_FAILURE); /* usage message by request */ if (directory == NULL) directory = TZDIR; if (yitcommand == NULL) -- Joseph S. Myers jsm(a)polyomino.org.uk

2 2

Australian timezone on Linux
by Girish Hilage Jan. 1, 2009

Jan. 1, 2009

Hi, I have a problem setting the Australian DST timezone on my Fedora Core 8 system. When DST starts it is able to advance the time by an hour but the time does not wind back by an hour while DST ends. I am using timezone "South Australia". DST start : [girish@mymachine Australia]$ date Sun Oct 5 01:59:57 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 01:59:58 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 03:00:00 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 03:00:03 CST 2008 DST end : [girish@mymachine Australia]$ date Sun Apr 5 02:59:57 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 02:59:59 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 03:00:01 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 03:00:02 CST 2009 This is also not working for Apr 6 08. Is there any reason why is it not working properly? Regards, Girish DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

6 5

FW: New Location request
by Olson, Arthur David (NIH/NCI) [E] Dec. 30, 2008

Dec. 30, 2008

I'm forwarding this message from Marek Hajduczenia, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. MH: there's already a GMT-12 binary in the distributed version of the package; it is named "Etc/GMT-12." But using the name "GMT-12" should do what you want on the largest number of computers. --ado -----Original Message----- From: Marek Hajduczenia [mailto:marek_haj@2com.pl] Sent: Tuesday, December 23, 2008 2:42 To: 'Paul Eggert'; tz(a)lecserver.nci.nih.gov Subject: RE: FW: New Location request Hi Paul, Thank You for the answer. GMT-12 hrs would resolve the problem since I need to track time and day. It is critical since the ballots close e.g. xx.xx.2009 at 11.59 AOE, so that way I can trace what day and what hour is in Howland Island time zone. If Howland Island is not a good location, please add simply GMT-12 and provide the name as AOE (Anywhere On Earth reference). Is that possible ? Regards Marek Hajduczenia -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: segunda-feira, 22 de Dezembro de 2008 23:17 To: tz(a)elsie.nci.nih.gov Cc: marek_haj(a)2com.pl Subject: Re: FW: New Location request > From: Marek Hajduczenia [mailto:marek_haj@2com.pl] > Sent: Saturday, December 20, 2008 3:30 > I am writing to You with a small request. Is it possible to add one > location to time zone data base app i.e. Howland Island (see: > http://www.worldtimezone.com/time/wtzresult.php?CiID=42242) It is > used heavily in IEEE ballots as the Anywhere On Earth time locator and > it would be nice to have. Me and my colleagues use various plugins > which in turns use this data base for reference and currently this > location is not available. I do realize that this is not an inhabited > island though there is some point of merit in adding it to the > list. Alternatively, adding any location which has GMT-12 hrs would be > of use, no matter what the name is. It would be most useful for IEEE > community (I am speaking here as its member only). Would TZ='Etc/GMT+12' solve your problem? As far as we know, Howland was using Hawaii War Time (9.5 hours behind UTC) the last time that it was inhabited, so I'm afraid it's not a good representative for the zone that is 12 hours behind UTC.

2 1

question about Argentina 1946 - 1963
by Alois Treindl Dec. 29, 2008

Dec. 29, 2008

In the Argentina timezone rules I find a strange fact: continuous DST from Oct 1946 to Oct 1963. The rules are: Rule Arg 1946 only - Mar 1 0:00 0 - Rule Arg 1946 only - Oct 1 0:00 1:00 S Rule Arg 1963 only - Oct 1 0:00 0 - Rule Arg 1963 only - Dec 15 0:00 1:00 S There are no other rules affecting the years 1946 or 1963 or any year in between. This means that Argentina was continuously on DST. Is this really correct, and what are the sources for that?

1 0

FW: New Location request
by Olson, Arthur David (NIH/NCI) [E] Dec. 23, 2008

Dec. 23, 2008

I'm forwarding this message from Marek Hajduczenia, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: Marek Hajduczenia [mailto:marek_haj@2com.pl] Sent: Saturday, December 20, 2008 3:30 To: tz(a)lecserver.nci.nih.gov Subject: New Location request Dear Sir/Madam, I am writing to You with a small request. Is it possible to add one location to time zone data base app i.e. Howland Island (see: http://www.worldtimezone.com/time/wtzresult.php?CiID=42242) It is used heavily in IEEE ballots as the Anywhere On Earth time locator and it would be nice to have. Me and my colleagues use various plugins which in turns use this data base for reference and currently this location is not available. I do realize that this is not an inhabited island though there is some point of merit in adding it to the list. Alternatively, adding any location which has GMT-12 hrs would be of use, no matter what the name is. It would be most useful for IEEE community (I am speaking here as its member only). If You have any comments, please let me know. Kindest regards Marek Hajduczenia

3 2

tzdata for Switzerland 1940 - 1942 probably incorrect - PS
by Alois Treindl Dec. 16, 2008

Dec. 16, 2008

I forgot to correct the begin times. These must be according to the meteorological federal office: The rules must be changed to Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - or made explicit for these two years, 1941 and 1942. The rule for 1940 must be deleted. Best regards Alois Treindl -- || Dr. Alois Treindl, Astrodienst AG, mailto:alois@astro.com || Zollikon/Zurich, Switzerland || Free astrological charts at http://www.astro.com/ || SWISS EPHEMERIS Free Edition at http://www.astro.com/swisseph/

1 1

tzdata for Switzerland 1940 - 1942 probably incorrect
by Alois Treindl Dec. 15, 2008

Dec. 15, 2008

Hello tzdata currently has these rules for Switzerland: # From Whitman (who writes ``Midnight?''): Rule Swiss 1940 only - Nov 2 0:00 1:00 S Rule Swiss 1940 only - Dec 31 0:00 0 - # From Shanks & Pottenger: Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 - These are most likely incorrect. I have been practicing astrology in Switzerland since 1980 (in recent years running the website www.astro.com) and have never come upon any source which claimed DST in Switzerland for 1940. A current source is for example metas.ch/metasweb/Themen/sommerzeit;internal which is the Federal office for meteorology. This page has (near the bottom) Sommerzeit 1941 bis 1942 Bei Beginn wurden die Uhren von 01:00 auf 02:00 Uhr vorgestellt und am Ende entsprechend von 02:00 auf 01:00 h zurückgestellt. (begin at 1 am, clocks shifted to 2am; end 2am, clocks shifted to 1 am) 1942 begin 4. Mai end 5. Oktober 1941 begin 5. Mai end 6. Oktober This is what Shanks has in the International Atlas, all editions. He is wrongly quoted in tzdata. 5 may 1941 is a monday, 6 Oct 1942 is a monday. 4 may 1942 and 5 Oct 1942 are also mondays. The rules must either be changed to Rule Swiss 1941 1942 - May Mon>=1 2:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 0:00 0 - or made explicit for these two years, 1941 and 1942. The rule for 1940 must be deleted. Best regards Alois Treindl -- || Dr. Alois Treindl, Astrodienst AG, mailto:alois@astro.com || Zollikon/Zurich, Switzerland || Free astrological charts at http://www.astro.com/ || SWISS EPHEMERIS Free Edition at http://www.astro.com/swisseph/

1 0

time during standard to DST transition
by Jennifer Wang (jennifwa) Dec. 12, 2008

Dec. 12, 2008

Hello, We ran into a problem when setting time to the "missing hour" during transition from standard time to DST time. For example, setting time to Mar 8, 2009 at 2:10am using America/Los_Angeles time zone results in error. Should mktime() skip forward in this case and set the time to Mar 8, 2009 3:10am? Jennifer

3 5

Mahe India TZ off 1 hr 30 min
by Julie Delany Dec. 11, 2008

Dec. 11, 2008

Hi, I found that Mahe, India (Mahe is the only city in India in the TZ? It's all one timezone anyway) has an error in the tz database. Per the world clock's meeting time program (using the TZ?): http:// www.timeanddate.com/worldclock/meetingtime.html? month=12&day=17&year=2008&p1=44&p2=224&p3=179&p4=-1 If it is 10:00 am Los Angeles time Wednesday Dec 17th, 2008, it is 11:30 p.m. in Mahe/Mumbai/India. But when I'm using the TZ in my perl program I get 10:00 p.m. Could you check that out for me? I've had to update my perl script to add 1 hour & 30 min. Thanks, julie

1 1

FW: Wrong Argentinian DST introduced in version 2008f
by Olson, Arthur David (NIH/NCI) [E] Dec. 11, 2008

Dec. 11, 2008

I'm forwarding this message from Aurelien Jarno, who is not on the time zone mailing list. Those of you who are on the time zone mailing list, please direct replies appropriately. --ado -----Original Message----- From: Aurelien Jarno [mailto:aurelien@aurel32.net] Sent: Monday, October 06, 2008 9:29 To: tz(a)lecserver.nci.nih.gov Subject: Wrong Argentinian DST introduced in version 2008f Hi, tzdata version 2008f introduced a rule for Argentinian DST based on http://www.worldtimezone.com/dst_news/dst_news_argentina03.html and http://www.impulsobaires.com.ar/nota.php?id=57832 Unfortunately those links only speak about rumors of a DST change, there is nothing fixed officially, and according to some Argentinian people DST may even not happen this year. Until an official decision is taken it is probably a lot better to remove any DST rule for year 2008. Please find attached a patch to do that. Regards, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32(a)debian.org | aurelien(a)aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net

4 3

Fwd: zdump loop problem
by Jonathan Leffler Dec. 11, 2008

Dec. 11, 2008

Originally sent to the wrong email address - sorry. ---------- Forwarded message ---------- From: Jonathan Leffler <jonathan.leffler(a)gmail.com> Date: Mon, Dec 8, 2008 at 12:14 PM Subject: Re: zdump loop problem To: Robbin Kawabata <Robbin.Kawabata(a)sun.com> Cc: tz(a)lecserver.nci.nih.gov, a.radke(a)arcor.de On Mon, Dec 8, 2008 at 11:50 AM, Robbin Kawabata <Robbin.Kawabata(a)sun.com>wrote: > I ran ado's fix against all the timezones, and got good results. > > This is the diff: > > *** zdump_loop.c Tue Dec 2 11:17:01 2008 > --- zdump_fix_ado.c Tue Dec 2 12:49:05 2008 > *************** > *** 312,322 **** > (void) strncpy(buf, abbr(&tm), sizeof (buf) - 1); > } > for (;;) { > ! if (t >= cuthitime) > break; > newt = t + SECSPERHOUR * 12; > - if (newt >= cuthitime) > - break; > if (newt <= t) > break; > newtmp = localtime(&newt); > --- 312,320 ---- > (void) strncpy(buf, abbr(&tm), sizeof (buf) - 1); > } > for (;;) { > ! if (t >= cuthitime || t >= cuthitime - SECSPERHOUR > * 12) > break; > Isn't that code equivalent to just: if (t >= cuthitime - SECSPERHOUR * 12) I've not followed all the details of the thread, but AFAIUI, this code is protecting against overflow on positive quantities (rather than underflow on negative ones), and the double test is redundant unless cuthitime is within 12 * SECPERHOUR of the smallest (most negative) integer. > newt = t + SECSPERHOUR * 12; > if (newt <= t) > break; > newtmp = localtime(&newt); > > > However, isn't the check for "if (newt <= t) break" no longer needed? > Probably... > ----- Begin Forwarded Message ----- > > Date: Mon, 01 Dec 2008 16:21:00 -0500 > From: "Olson, Arthur David (NIH/NCI) [E]" <olsona(a)dc37a.nci.nih.gov> > Subject: Re: zdump loop problem > To: tz(a)lecserver.nci.nih.gov > Cc: Andreas Radke <a.radke(a)arcor.de> > > So...in the real world, does changing the zic.c lines reading... > if (t >= cuthitime) > break; > newt = t + SECSPERHOUR * 12; > if (newt >= cuthitime) > break; > ...to read... > if (t >= cuthitime || t >= cuthitime - > SECSPERHOUR * 12) > break; > newt = t + SECSPERHOUR * 12; > ...result in working code? I'd particularly appreciate feedback from > Andreas Radke or other ArchLinux users. > > ----- End Forwarded Message ----- > -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

FW: Cuba 2004-2006
by Olson, Arthur David (NIH/NCI) [E] Dec. 10, 2008

Dec. 10, 2008

I'm forwarding this message from hsv(a)tbbs.net, who is not on the time zone mailing list (at least not at that address). Those of you who are on the list, please direct replies appropriately. Hsv is correct that there's no real shift in April 2005 or April 2006. While the current rules do the right thing, I plan to include a change from... Rule Cuba 2000 2006 - Apr Sun>=1 0:00s 1:00 D ...to... Rule Cuba 2000 2004 - Apr Sun>=1 0:00s 1:00 D ...in the next bundle of changes for clarity. --ado -----Original Message----- From: hsv(a)tbbs.net [mailto:hsv@tbbs.net] Sent: Sunday, December 07, 2008 12:19 To: tz(a)lecserver.nci.nih.gov Subject: Cuba 2004-2006 This looks queer: Rule Cuba 1998 2003 - Oct lastSun 0:00s 0 S Rule Cuba 2000 2006 - Apr Sun>=1 0:00s 1:00 D Rule Cuba 2006 max - Oct lastSun 0:00s 0 S I take the foregoing for something like this: ... 2003 Apr Sun>=1 0:00s 1:00 D 2003 Oct lastSun 0:00s 0 S 2004 Apr Sun>=1 0:00s 1:00 D 2005 Apr Sun>=1 0:00s 1:00 D 2006 Apr Sun>=1 0:00s 1:00 D 2006 Oct lastSun 0:00s 0 S ... but at those Aprils in 2005 and 2006 there is no real shift. Is this right?

1 0

Brazil rule issue
by Alain Petit Dec. 10, 2008

Dec. 10, 2008

Hi I am looking in the Brazil rules and I was wondering if this was expected: <snapshot> Rule Brazil 2007 only - Oct Sun>=8 0:00 1:00 S # From Frederico A. C. Neves (2008-09-10): # Acording to this decree # <a href="http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm"> # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm # </a> # [t]he DST period in Brazil now on will be from the 3rd Oct Sunday to the # 3rd Feb Sunday. There is an exception on the return date when this is # the Carnival Sunday then the return date will be the next Sunday... Rule Brazil 2008 max - Oct Sun>=15 0:00 1:00 S Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - Rule Brazil 2016 2022 - Feb Sun>=15 0:00 0 - Rule Brazil 2023 only - Feb Sun>=22 0:00 0 - Rule Brazil 2024 2025 - Feb Sun>=15 0:00 0 - Rule Brazil 2026 only - Feb Sun>=22 0:00 0 - Rule Brazil 2027 2033 - Feb Sun>=15 0:00 0 - Rule Brazil 2034 only - Feb Sun>=22 0:00 0 - Rule Brazil 2035 2036 - Feb Sun>=15 0:00 0 - Rule Brazil 2037 only - Feb Sun>=22 0:00 0 - # From Arthur David Olson (2008-09-29): # The next is wrong in some years but is better than nothing. Rule Brazil 2038 max - Feb Sun>=15 0:00 0 - </snapshot> There is 2 'max' entry for Brazil, one for 2008, and one for 2038. Rule Brazil 2008 max - Oct Sun>=15 0:00 1:00 S Rule Brazil 2038 max - Feb Sun>=15 0:00 0 - Reading the entries for 2012+ I feel that the one for 2008 should be a 'only' rather than 'max'. Is that correct? Thanks Alain Petit

8 12