- tz - lists.iana.org

RE: Web service time computer
by Phillip Guerra Feb. 24, 2006

Feb. 24, 2006

If the rule Markus presents is enacted anywhere, exactly how would that fit into the present coding scheme? :) I would not champion changing the master format, but do feel alternate formats could be made available for use with disparate systems. Yes, many folks have to program for more than 1 operating system and the effort would be worthwhile to keep the current datastore as the common standard. I won't argue for presentation of an xml version for the sake of stability, but rather would think the issue is making the datastore easier to integrate into other systems. Is XML the best format? I wouldn't say, but having spent a great deal of time parsing and converting many healthcare related datasets from one system to another, it was really an improvement to see HL7 introduced years ago. Something similar would be appreciated with this type of information, maybe not exactly XML, but a protocol that allows greater flexibility for use in sharing info between disparate systems. Once the metadata is transferred, a 'conversion' utility can be used to put it into a form most efficient for the host or target system. Web administrators need a common approach to the issue of presenting date time and date time interpolation that are not bound to operating systems, and a host machines' registry. It's an issue that is shared with users of all types of operating systems. I don't care about a programmers preference, use what you need, but at least have a common datastore for needed elements. At present, I'm using the tzinfo datastore, and parsing it for use on a Windows .Net framework. An alternate format would have been nice to use, as it was a challenge to get my head and arms around the format of the datastore not knowing about the zic utility, or other Posix type languages. My lack of skills in those areas is at fault not the datastores' exactly. I'll continue to use the tzinfo datastore in the current format because I believe it is the closest to fullfilling the need for common usage. However, I do see positives for presenting alternate formats using a common metadata. Cheers -----Original Message----- From: Markus Kuhn [mailto:Markus.Kuhn@cl.cam.ac.uk] Sent: Friday, February 24, 2006 11:49 AM To: tz(a)lecserver.nci.nih.gov Subject: Re: Web service time computer Deborah Goldsmith wrote on 2006-02-24 15:13 UTC: > On Feb 24, 2006, at 1:35 AM, Markus Kuhn wrote: > >> It might be better to maintain TZDATA in xml and have a translator > >> back to the current format. > > > > And the advantage would be what exactly? > > Stability, so that tools that parse the data can deal with change more > gracefully. The ICU project has had a difficult time keeping up with > changes to the file and tools. We can't use the output files -- which > *are* stable -- because they do not contain all the data from the > input that ICU needs. > > However, I don't care whether the "master" copy is XML or not, just > that it is possible to generate XML (or some other stable format) from > the "official" version of zic, so that when the timezone file format > changes, or zic changes, the stable format doesn't change. I understand. But also consider that if the timezone file format changes, there may be a good reason for such a change, i.e. a newly required functionality. We are at the mercy of creative politicians all over the world, who continue to think up new and innovative ways for fiddling with local time. They will be as little restricted by your desired XML DTD as they are currently restricted by the zic input file format. "DST shall henceforth start on the first Monday after the first Tuesday after the latest Wednesday before the full moon closest to Easter, exept if the year is divisible by 400, in which case we follow the European Union rules of 1992." Markus

1 0

RE: Web service time computer
by Phillip Guerra Feb. 23, 2006

Feb. 23, 2006

I've done a conversion of the tzinfo datastore to use with MS .Net concentric apps. One of the issues encountered is the need to expand the info to hold discrete records for the years named for rules, and zones. For example, the number of rules created are over 4,500+. Properly indexed, I don't see an issue with the number of rules. However, I still need to test the approach with example apps and usage cases. The information is a simple ascii file, similar to tzinfo, and a parsing program could be used to create other forms of the data like xml or database info. I would think the xml file would be useful for that purpose or even the expanded raw file to use for whatever further processing was required. The need for me was to provide the info for use by web apps which may be limited by security issues to use a host's system information, which on MS systems has no capability for historical reference, limited to the current year, and is known to be be less accurate. Still not sure if this is the most efficient method to go about it, but I found nothing like it in my searching for a similar solution. Most MS solutions are using the registry info, which has the above mentioned issues, and therefore not optimum. -----Original Message----- From: Paul Schauble [mailto:Paul.Schauble@ticketmaster.com] Sent: Thursday, February 23, 2006 2:59 PM To: tz(a)lecserver.nci.nih.gov; tz(a)lecserver.nci.nih.gov Subject: RE: Web service time computer It might be better to maintain TZDATA in xml and have a translator back to the current format. ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Deborah Goldsmith Sent: Thursday, February 23, 2006 1:00 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Web service time computer On Feb 23, 2006, at 8:59 AM, Andy Lipscomb wrote: > I've actually been trying to use this data to implement time zone > conversion in REALbasic, and one of the steps in doing so has proven > to be rewriting the data files in XML. I could contribute that much to > the efforts. > Actually, the ICU team is very interested in getting this data in an XML form as well. One of the projects on my to-do list is to make a proposal for changes to zic that would optionally emit a (stable) XML version of the data. If someone else gets to this first I would be happy to help. Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. goldsmit(a)apple.com

1 0

Web service time computer
by Andy Lipscomb Feb. 23, 2006

Feb. 23, 2006

I've actually been trying to use this data to implement time zone conversion in REALbasic, and one of the steps in doing so has proven to be rewriting the data files in XML. I could contribute that much to the efforts.

2 1

zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)
by Paul Eggert Feb. 23, 2006

Feb. 23, 2006

The command "zdump -v US/Pacific" took 36 CPU seconds on my (admittedly aging) 440 MHz UltraSPARC-IIi machine. There are no doubt other speedups that could be done, but the following obvious one shrank the CPU time to 20 CPU seconds. Standard time wasn't introduced before 1800 anywhere that I know of. --- zdump.8 2006/02/20 15:08:17 2006.2 +++ zdump.8 2006/02/23 17:29:26 2006.2.0.1 @@ -41,7 +41,7 @@ otherwise. .BI "\-c " [loyear,]hiyear Cut off verbose output near the start of the given year(s). By default, -the program cuts off verbose output near the starts of the years -500 and 2500. +the program cuts off verbose output near the starts of the years 1800 and 2500. .SH LIMITATIONS The .B \-v --- zdump.c 2006/02/21 21:07:30 2006.2.0.1 +++ zdump.c 2006/02/23 17:29:26 2006.2.0.2 @@ -18,7 +18,7 @@ static char elsieid[] = "@(#)zdump.c 8.1 #endif /* !defined isascii */ #ifndef ZDUMP_LO_YEAR -#define ZDUMP_LO_YEAR (-500) +#define ZDUMP_LO_YEAR 1800 #endif /* !defined ZDUMP_LO_YEAR */ #ifndef ZDUMP_HI_YEAR

1 0

RE: First Sunday
by Olson, Arthur David (NIH/NCI) [E] Feb. 23, 2006

Feb. 23, 2006

If we were starting over, additions such as "1stMon" would be the way to go. However, given all those time zone compilers out in the field that don't understand "1stMon", and given that there's a way of representing the desired input that those compilers do understand, my sense would be to stick with the existing mechanism in the data files. --ado > > And while we're on that subject, there are several lastSuns and a > > lastSat in Zone entries (which inherently refer to just one > > occurrence). Would it be better to replace those with the appropriate actual days? > How about avoiding >= -v- <= issues altogether, along with the occasional counting problems, by introducing synonyms like "1stMon", "2ndSun", etc. > While not strictly necessary like their "last..." brethren, if clarity of expression is the goal then I proffer that they are just the ticket.

1 0

RE: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz
by Chris Walton-TM Feb. 23, 2006

Feb. 23, 2006

The 2006b data looks the same as the 2006a data. The only thing that changed was the version numbers. I am still hoping to see an update to "America/Edmonton" reflecting the extra 4 weeks of Daylight Savings starting in 2007. Rather than creating new entries for the "Edm" rules, it would probably be easier to start using the "Canada" rules... but I leave this up to the experts. Thanks -chris P.S. Hopefully this e-mail doesn't start another war over naming conventions. I have intentionally left "Canada/Edmonton" out of the subject line. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: February 20, 2006 10:15 AM To: tz(a)lecserver.nci.nih.gov Subject: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz The files... ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz32code2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz64code2006b.tar.gz ...are now available. The files... ftp://elsie.nci.nih.gov/pub/classictzcode.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/classictzdata.tar.gz ...have been removed. The 32-bit code is there for folks who may need it; with providence, there will be little or no need to update it. The 64-bit code reflects the changes circulated earlier on the time zone mailing list. Both the 32-bit code and the 64-bit code share the same data. All SCCS IDs were bumped to "8.1" for this release. --ado

2 1

[patch] misc build touchups
by Mike Frysinger Feb. 22, 2006

Feb. 22, 2006

this patch: - adds support for DESTDIR (`make install DESTDIR=/foo`) - respects LDFLAGS set in the environment - respects CFLAGS set in the environment -mike

1 0

RE: First Sunday
by Phillip Guerra Feb. 22, 2006

Feb. 22, 2006

I hesitate to reply, as I'm a relative newbie to this list, and I may be way off base. However, would it not be easier to implement a coding scheme for this field that maps an occurrence of a day within a month e.g. W-D where W is the Day of the Week, 1 - Sun, 2 - Mon thru 7 - Sat O is the occurrence of that day within the month 1-1st, 2-2nd, 3-3rd, 4-4th, 5 - Last 1-1 translates to 'the first Sunday' 1-5 translates to 'the last Sunday' 7-3 translates to 'the 3rd Saturday' and so on... It would seem to remove any misinterpretation. Just a newbie thought... I, also think that since the historical references are not going to change with respect to the day, so that it might as well be represented with the actual day and date. Again, just a newbie thought... -----Original Message----- From: Dave Cantor [mailto:Dave@Cantor.mv.com] Sent: Wednesday, February 22, 2006 1:27 PM To: tz(a)lecserver.nci.nih.gov Subject: RE: First Sunday On 22 Feb 2006 at 13:45, Andy Lipscomb wrote: > And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? Maybe, but that won't work for a rule indicating lastSun in February which may be in effect both during leap years and during non-leap years. (I didn't check -- I'm guessing that there are none.) Dave C. -- Dave Cantor Groton, CT 06340-3731 Dave(a)Cantor.mv.com

1 0

RE: First Sunday
by Andy Lipscomb Feb. 22, 2006

Feb. 22, 2006

These aren't DST rules I'm talking about--these are transition points, which only occur once. I wasn't suggesting that for DST rules that would apply to more than one year. -----Original Message----- From: Dave Cantor [mailto:Dave@cantor.mv.com] Sent: Wed 22 February 2006 14:27 To: tz(a)lecserver.nci.nih.gov Subject: RE: First Sunday On 22 Feb 2006 at 13:45, Andy Lipscomb wrote: > And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? Maybe, but that won't work for a rule indicating lastSun in February which may be in effect both during leap years and during non-leap years. (I didn't check -- I'm guessing that there are none.) Dave C. -- Dave Cantor Groton, CT 06340-3731 Dave(a)Cantor.mv.com

1 0

RE: First Sunday
by Andy Lipscomb Feb. 22, 2006

Feb. 22, 2006

And while we're on that subject, there are several lastSuns and a lastSat in Zone entries (which inherently refer to just one occurrence). Would it be better to replace those with the appropriate actual days? -----Original Message----- From: Paul Eggert [mailto:eggert@CS.UCLA.EDU] Sent: Wed 22 February 2006 13:30 To: tz(a)lecserver.nci.nih.gov Subject: Re: First Sunday Jesper Norgaard Welen <jnorgard(a)prodigy.net.mx> writes: > I would recommend using "Sun>=1", because I think it is clearer. Thanks for the suggestion. I'll remove the "<="s in my next proposed patch. There are also instances of "Mon<=7", "Sat<=7", "Sun<=14", "Sun<=21", and "Sun<=24", which can all be rewritten.

2 1

Macau use of PRC
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

In the asia file, there is a rule PRC defined which is used for quite a number of timezones: Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D However, putting it to use in Macau seems superfluous since the PRC rule is inactive since 1991, and it is implemented for Macau only in december 1999: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 PRC C%sT Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Hiccup in Easter Island 1982
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

It seems unlikely that Easter Island changed from GMT-6 to GMT-7 for 4 hours (from 20 to 24) on 14 th. of March 1982, and then switched back to GMT-6. Rather it is more likely they stayed on the same time, by changing from one rule to another on 13.th of March at 21:00, which results in no time change at all on 13.th. or 14.th. of March in Easter Island. I don't know if this is something zic mends, but at least the Jodatime java package which uses the tz data directly, reflects this double DST change in their extracted data files, while Jodatime handles gracefully (zic-like) the hiccups of this type that only lasts for an hour (for instance the Knox Indiana change that was discussed earlier). Old rule: -7:00 Chile EAS%sT 1982 Mar 14 # Easter I Time -6:00 Chile EAS%sT New rule: -7:00 Chile EAS%sT 1982 Mar 13 21:00 # Easter I Time -6:00 Chile EAS%sT Regards, - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

First Sunday
by Jesper Norgaard Welen Feb. 22, 2006

Feb. 22, 2006

There are a few instances in the tz database where a rule is using the string "Sun<=7" rather than "Sun>=1" to mean the first Sunday in the month. I would recommend using "Sun>=1", because I think it is clearer. At least I confused "Sun<=7" with "Sun>=7" once when reading these rules, which is quite a different thing. In the africa file: Rule Algeria 1916 1919 - Oct Sun<=7 23:00s 0 - In the antarctica file: Rule ArgAQ 1967 1968 - Oct Sun<=7 0:00 1:00 S Rule ArgAQ 1968 1969 - Apr Sun<=7 0:00 0 - ... Rule ArgAQ 1974 1976 - Oct Sun<=7 0:00 1:00 S Rule ArgAQ 1975 1977 - Apr Sun<=7 0:00 0 - Regards, - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

tz changes to pacify GCC 4.0.2 on Solaris 8
by Paul Eggert Feb. 22, 2006

Feb. 22, 2006

When compiling the latest tz code with GCC 4.0.2 on Solaris 8 (64-bit), I got some warnings that looked like this: zic.c:979: warning: comparison between signed and unsigned zic.c:1086: warning: comparison between signed and unsigned asctime.c:106: warning: '0' flag ignored with precision and '%d' printf format Here are proposed patches to remove all the places where I observed problems in this area. Not all the size_t-related problems were caught by GCC, but I expect other compilers might have similar complaints, so I figured I might as well fix them all while I was thinking about it. Since the affected quantities are all too small to be worried about overflowing a signed 16-bit quantity on practical machines, I don't think this patch fixes any real-world bugs or changes any real-world behavior, except perhaps that it makes the code a bit smaller and faster on 64-bit hosts because we don't keep converting 64-bit quantities to 32 bits and back. =================================================================== RCS file: RCS/private.h,v retrieving revision 2006.2.0.1 retrieving revision 2006.2.0.2 diff -pu -r2006.2.0.1 -r2006.2.0.2 --- private.h 2006/02/21 21:07:30 2006.2.0.1 +++ private.h 2006/02/22 00:24:05 2006.2.0.2 @@ -236,8 +236,8 @@ extern char * asctime_r(); char * icalloc P((int nelem, int elsize)); char * icatalloc P((char * old, const char * new)); char * icpyalloc P((const char * string)); -char * imalloc P((int n)); -void * irealloc P((void * pointer, int size)); +char * imalloc P((size_t n)); +void * irealloc P((void * pointer, size_t size)); void icfree P((char * pointer)); void ifree P((char * pointer)); const char * scheck P((const char * string, const char * format)); =================================================================== RCS file: RCS/ialloc.c,v retrieving revision 1997.3 retrieving revision 1997.3.0.1 diff -pu -r1997.3 -r1997.3.0.1 --- ialloc.c 1997/03/07 21:06:34 1997.3 +++ ialloc.c 2006/02/22 00:27:00 1997.3.0.1 @@ -12,9 +12,9 @@ static char elsieid[] = "@(#)ialloc.c 8. char * imalloc(n) -const int n; +const size_t n; { - return malloc((size_t) nonzero(n)); + return malloc(nonzero(n)); } char * @@ -30,11 +30,11 @@ int elsize; void * irealloc(pointer, size) void * const pointer; -const int size; +const size_t size; { if (pointer == NULL) return imalloc(size); - return realloc((void *) pointer, (size_t) nonzero(size)); + return realloc((void *) pointer, nonzero(size)); } char * @@ -43,7 +43,7 @@ char * const old; const char * const new; { register char * result; - register int oldsize, newsize; + register size_t oldsize, newsize; newsize = (new == NULL) ? 0 : strlen(new); if (old == NULL) =================================================================== RCS file: RCS/localtime.c,v retrieving revision 2006.2.0.1 retrieving revision 2006.2.0.2 diff -pu -r2006.2.0.1 -r2006.2.0.2 --- localtime.c 2006/02/21 21:07:30 2006.2.0.1 +++ localtime.c 2006/02/22 00:24:05 2006.2.0.2 @@ -340,8 +340,9 @@ register const int doextend; register const char * p; register int i; register int fid; - register int stored; - register int nread; + register int read_return; + register size_t stored; + register size_t nread; union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + @@ -385,12 +386,14 @@ register const int doextend; if ((fid = open(name, OPEN_MODE)) == -1) return -1; } - nread = read(fid, u.buf, sizeof u.buf); - if (close(fid) < 0 || nread <= 0) + read_return = read(fid, u.buf, sizeof u.buf); + if (close(fid) < 0 || read_return <= 0) return -1; + nread = read_return; for (stored = 4; stored <= 8; stored *= 2) { int ttisstdcnt; int ttisgmtcnt; + size_t j; ttisstdcnt = (int) detzcode(u.tzhead.tzh_ttisstdcnt); ttisgmtcnt = (int) detzcode(u.tzhead.tzh_ttisgmtcnt); @@ -511,12 +514,12 @@ register const int doextend; if (u.tzhead.tzh_version[0] == '\0') break; nread -= p - u.buf; - for (i = 0; i < nread; ++i) - u.buf[i] = p[i]; + for (j = 0; j < nread; ++j) + u.buf[j] = p[j]; /* ** If this is a narrow integer time_t system, we're done. */ - if (stored >= (int) sizeof(time_t) && TYPE_INTEGRAL(time_t)) + if (stored >= sizeof(time_t) && TYPE_INTEGRAL(time_t)) break; } if (doextend && nread > 2 && =================================================================== RCS file: RCS/scheck.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- scheck.c 2006/02/20 15:08:17 2006.2 +++ scheck.c 2006/02/22 00:24:05 2006.2.0.1 @@ -23,7 +23,7 @@ const char * const format; result = ""; if (string == NULL || format == NULL) return result; - fbuf = imalloc((int) (2 * strlen(format) + 4)); + fbuf = imalloc(2 * strlen(format) + 4); if (fbuf == NULL) return result; fp = format; =================================================================== RCS file: RCS/zic.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- zic.c 2006/02/20 15:08:17 2006.2 +++ zic.c 2006/02/22 00:24:05 2006.2.0.1 @@ -167,8 +167,8 @@ static int leapseen; static int leapminyear; static int leapmaxyear; static int linenum; -static int max_abbrvar_len; -static int max_format_len; +static size_t max_abbrvar_len; +static size_t max_format_len; static zic_t max_time; static int max_year; static zic_t min_time; @@ -979,7 +979,7 @@ const int nfields; if (max_abbrvar_len < strlen(r.r_abbrvar)) max_abbrvar_len = strlen(r.r_abbrvar); rules = (struct rule *) (void *) erealloc((char *) rules, - (int) ((nrules + 1) * sizeof *rules)); + (nrules + 1) * sizeof *rules); rules[nrules++] = r; } @@ -996,7 +996,7 @@ const int nfields; return FALSE; } if (strcmp(fields[ZF_NAME], TZDEFAULT) == 0 && lcltime != NULL) { - buf = erealloc(buf, (int) (132 + strlen(TZDEFAULT))); + buf = erealloc(buf, 132 + strlen(TZDEFAULT)); (void) sprintf(buf, _("\"Zone %s\" line and -l option are mutually exclusive"), TZDEFAULT); @@ -1004,7 +1004,7 @@ _("\"Zone %s\" line and -l option are mu return FALSE; } if (strcmp(fields[ZF_NAME], TZDEFRULES) == 0 && psxrules != NULL) { - buf = erealloc(buf, (int) (132 + strlen(TZDEFRULES))); + buf = erealloc(buf, 132 + strlen(TZDEFRULES)); (void) sprintf(buf, _("\"Zone %s\" line and -p option are mutually exclusive"), TZDEFRULES); @@ -1014,7 +1014,7 @@ _("\"Zone %s\" line and -p option are mu for (i = 0; i < nzones; ++i) if (zones[i].z_name != NULL && strcmp(zones[i].z_name, fields[ZF_NAME]) == 0) { - buf = erealloc(buf, (int) (132 + + buf = erealloc(buf, (132 + strlen(fields[ZF_NAME]) + strlen(zones[i].z_filename))); (void) sprintf(buf, @@ -1112,7 +1112,7 @@ const int iscont; } } zones = (struct zone *) (void *) erealloc((char *) zones, - (int) ((nzones + 1) * sizeof *zones)); + (nzones + 1) * sizeof *zones); zones[nzones++] = z; /* ** If there was an UNTIL field on this line, @@ -1249,7 +1249,7 @@ const int nfields; l.l_from = ecpyalloc(fields[LF_FROM]); l.l_to = ecpyalloc(fields[LF_TO]); links = (struct link *) (void *) erealloc((char *) links, - (int) ((nlinks + 1) * sizeof *links)); + (nlinks + 1) * sizeof *links); links[nlinks++] = l; } @@ -1557,7 +1557,7 @@ const char * const string; ++leapi32; } fullname = erealloc(fullname, - (int) (strlen(directory) + 1 + strlen(name) + 1)); + strlen(directory) + 1 + strlen(name) + 1); (void) sprintf(fullname, "%s/%s", directory, name); /* ** Remove old file, if any, to snap links. @@ -1942,8 +1942,8 @@ const int zonecount; register char * startbuf; register char * ab; register char * envvar; - register int max_abbr_len; - register int max_envvar_len; + register size_t max_abbr_len; + register size_t max_envvar_len; max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; @@ -2310,7 +2310,7 @@ const char * const type; if (type == NULL || *type == '\0') return TRUE; - buf = erealloc(buf, (int) (132 + strlen(yitcommand) + strlen(type))); + buf = erealloc(buf, 132 + strlen(yitcommand) + strlen(type)); (void) sprintf(buf, "%s %d %s", yitcommand, year, type); result = system(buf); if (WIFEXITED(result)) switch (WEXITSTATUS(result)) { @@ -2401,7 +2401,7 @@ register char * cp; if (cp == NULL) return NULL; array = (char **) (void *) - emalloc((int) ((strlen(cp) + 1) * sizeof *array)); + emalloc((strlen(cp) + 1) * sizeof *array); nsubs = 0; for ( ; ; ) { while (isascii((unsigned char) *cp) && =================================================================== RCS file: RCS/asctime.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- asctime.c 2006/02/20 15:08:17 2006.2 +++ asctime.c 2006/02/22 00:24:05 2006.2.0.1 @@ -37,14 +37,24 @@ static char elsieid[] = "@(#)asctime.c 8 ** The ISO C 1999 and POSIX 1003.1-2004 standards prohibit padding the year, ** but many implementations pad anyway; most likely the standards are buggy. */ +#ifdef __GNUC__ +/* Avoid "warning: '0' flag ignored with precision and '%d' printf format". */ +#define ASCTIME_FMT "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %-4s\n" +#else #define ASCTIME_FMT "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %-4s\n" +#endif /* ** For years that are more than four digits we put extra spaces before the year ** so that code trying to overwrite the newline won't end up overwriting ** a digit within a year and truncating the year (operating on the assumption ** that no output is better than wrong output). */ +#ifdef __GNUC__ +/* Avoid "warning: '0' flag ignored with precision and '%d' printf format". */ +#define ASCTIME_FMT_B "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %s\n" +#else #define ASCTIME_FMT_B "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %s\n" +#endif #define STD_ASCTIME_BUF_SIZE 26 /*

1 0

Re: forego
by Mccabe Alisa Feb. 21, 2006

Feb. 21, 2006

testament Mr. Dick represented the Government or the Opposition as the case daughters station in life, the projects I may contemplate for her replicate such another position something else, entirely different; the mouth a little at the same time - and produced my last letter to

1 0

RE: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Feb. 21, 2006

Feb. 21, 2006

If we don't see reports of problems with the new stuff, I'll be happy to go with tzcode2006c.tar.gz rather than tz64code2006c.tar.gz on the next iteration; I wasn't inclined to be so prejudicial this time around. The question then becomes whether to change the name tz32code206b.tar.gz. Perhaps old-tzcode-32-bit-outputx.tar.gz would do the trick? --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Tuesday, February 21, 2006 4:06 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz "Olson, Arthur David \(NIH/NCI\) [E]" <olsona(a)dc37a.nci.nih.gov> writes: > ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz > ftp://elsie.nci.nih.gov/pub/tz32code2006b.tar.gz > ftp://elsie.nci.nih.gov/pub/tz64code2006b.tar.gz > > The 32-bit code is there for folks who may need it; with providence, > there will be little or no need to update it. This means we'll need to update the instructions in tz-link.htm, which currently say this: wget 'ftp://elsie.nci.nih.gov/pub/tz*.tar.gz' gzip -dc tzcode*.tar.gz | tar -xf - gzip -dc tzdata*.tar.gz | tar -xf - and this won't work nicely, due to the two code tarballs overridding each other. The names tz32code2006b.tar.gz and tz64code2006b.tar.gz are a bit confusing, since people might naturally get confused into thinking that the tarballs are for 32-bit and 64-bit development platforms, or for 32-bit and 64-bit runtime platforms, whereas neither is the case: they are really for 32-bit and 64-bit tz files, which is a different matter. Here's an idea. How about if we rename tz32code2006b.tar.gz to pre2038-tzcode2006b.tar.gz, and rename tz64code2006b.tar.gz back to tzcode2006b.tar.gz? That way, I won't have to change tz-link.htm (so it's less work for me :-), and also, users will be able to see more clearly why one might prefer the current to the previous version. Also, this naming convention fits in better with the recently-removed 'classictzcode' and 'classictzdata' convention. If you still prefer the current naming style, please let me know, so that I can propose a patch to tz-link.htm. Thanks.

1 0

Re: Message to `tz' mailing list
by Robert Elz Feb. 19, 2006

Feb. 19, 2006

Date: Fri, 17 Feb 2006 15:14:09 +0530 From: "N. Raghavendra" <raghu(a)mri.ernet.in> Message-ID: <867j7ugw0m.fsf(a)riemann.mri.ernet.in> | Perhaps I did not express my question clearly. I am trying to | understand how, given | | 1. an integer TIME (viewed as a number of seconds since the Epoch); | and | | 2. a TZFILE, | | one computes the wall clock time corresponding to TIME, in the time | zone defined by TZFILE. The wall clock time should be returned as a | broken-down time value, i.e., as a list of the form | | (SEC, MIN, HOUR, MDAY, MON, YEAR, WDAY, IS_DST, TZ_ABBREV, GMT_OFF) That's exactly what localtime() does isn't it? All the code is available (and free to use) - just use it (either the learn from, or simply to compile into your application). The raw tzfile isn't used of course, it is converted (using zic) into a binary format - but if you needed to you could combine the roles of zic and localtime into one function. kre

2 3

RE: Message to `tz' mailing list
by Olson, Arthur David (NIH/NCI) [E] Feb. 17, 2006

Feb. 17, 2006

> I am confused about the use of the UTC/local indicators and the standard/wall indicators in a tzfile. According to tzfile(5), they "are used when > a time zone file is used in handling POSIX-style time zone environment variables". Does this mean that these indicators are irrelevant when computing > local time using only a tzfile (without looking at the environment). That's correct: the ttisgmt and ttisstd indicators can be ignored if you're simply trying to figure out what wall clock time is for the zone that's associated with the file. (The indicators are there for the case when the time zone file is used as a "template" for the DST rules to be used when handling POSIX-style TZ environment variables; you need to know whether the transition time is defined in terms of UTC, local wall clock time, or local standard time to be able to know when translating the transition time for use in another zone.) --ado

3 2

Proposed tz code cleanups
by Arthur David Olson Feb. 16, 2006

Feb. 16, 2006

Along with the 64-bit changes previously circulated on the time zone list and due to show up in the ftp version on Monday, here are proposed STDC, long, and overflow cleanups from Paul Eggert and Ken Pizzini. diff -r -c old/date.c new/date.c *** old/date.c Thu Jan 26 10:19:21 2006 --- new/date.c Thu Feb 16 11:05:15 2006 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.42"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 7.44"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ *************** *** 254,260 **** struct timeval tv; tv.tv_sec = (int) adjust; ! tv.tv_usec = (int) ((adjust - tv.tv_sec) * 1000000); if (adjtime(&tv, (struct timeval *) NULL) != 0) oops("adjtime"); #endif /* HAVE_ADJTIME */ --- 254,260 ---- struct timeval tv; tv.tv_sec = (int) adjust; ! tv.tv_usec = (int) ((adjust - tv.tv_sec) * 1000000L); if (adjtime(&tv, (struct timeval *) NULL) != 0) oops("adjtime"); #endif /* HAVE_ADJTIME */ *************** *** 352,360 **** --- 352,364 ---- /*ARGSUSED*/ static void + #ifdef __STDC__ + reset(const time_t newt, const int nflag) + #else /* !defined __STDC__ */ reset(newt, nflag) const time_t newt; const int nflag; + #endif /* !defined __STDC__ */ { register int fid; time_t oldt; *************** *** 619,628 **** --- 623,636 ---- #define ATOI2(ar) (ar[0] - '0') * 10 + (ar[1] - '0'); ar += 2; static time_t + #ifdef __STDC__ + convert(register const char * const value, const int dousg, const time_t t) + #else /* !defined __STDC__ */ convert(value, dousg, t) register const char * const value; const int dousg; const time_t t; + #endif /* !defined __STDC__ */ { register const char * cp; register const char * dotp; *************** *** 726,736 **** --- 734,751 ---- */ static void + #ifdef __STDC__ + checkfinal(const char * const value, + const int didusg, + const time_t t, + const time_t oldnow) + #else /* !defined __STDC__ */ checkfinal(value, didusg, t, oldnow) const char * const value; const int didusg; const time_t t; const time_t oldnow; + #endif /* !defined __STDC__ */ { time_t othert; struct tm tm; *************** *** 789,799 **** --- 804,819 ---- } static void + #ifdef __STDC__ + iffy(const time_t thist, const time_t thatt, + const char * const value, const char * const reason) + #else /* !defined __STDC__ */ iffy(thist, thatt, value, reason) const time_t thist; const time_t thatt; const char * const value; const char * const reason; + #endif /* !defined __STDC__ */ { struct tm tm; diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Thu Jan 26 10:19:21 2006 --- new/localtime.c Thu Feb 16 11:07:47 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.97"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.98"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 510,518 **** --- 510,522 ---- */ static const char * + #ifdef __STDC__ + getqzname(register const char *strp, const char delim) + #else /* !defined __STDC__ */ getqzname(strp, delim) register const char * strp; const char delim; + #endif /* !defined __STDC__ */ { register char c; diff -r -c old/zdump.c new/zdump.c *** old/zdump.c Thu Jan 26 10:19:21 2006 --- new/zdump.c Thu Feb 16 11:16:58 2006 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 7.74"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.76"; /* ** This code has been made independent of the rest of the time *************** *** 15,21 **** #include "ctype.h" /* for isalpha et al. */ #ifndef isascii #define isascii(x) 1 ! #endif #ifndef ZDUMP_LO_YEAR #define ZDUMP_LO_YEAR (-500) --- 15,21 ---- #include "ctype.h" /* for isalpha et al. */ #ifndef isascii #define isascii(x) 1 ! #endif /* !defined isascii */ #ifndef ZDUMP_LO_YEAR #define ZDUMP_LO_YEAR (-500) *************** *** 418,431 **** } } else if (0 > (time_t) -1) { /* ! ** time_t is signed. */ ! register time_t hibit; ! for (hibit = 1; (hibit * 2) != 0; hibit *= 2) ! continue; ! absolute_min_time = hibit; ! absolute_max_time = -(hibit + 1); } else { /* ** time_t is unsigned. --- 418,438 ---- } } else if (0 > (time_t) -1) { /* ! ** time_t is signed. Assume overflow wraps around. */ ! time_t t = 0; ! time_t t1 = 1; ! while (t < t1) { ! t = t1; ! t1 = 2 * t1 + 1; ! } ! ! absolute_max_time = t; ! t = -t; ! absolute_min_time = t - 1; ! if (t < absolute_min_time) ! absolute_min_time = t; } else { /* ** time_t is unsigned. *************** *** 468,477 **** --- 475,488 ---- } static time_t + #ifdef __STDC__ + hunt(char *name, time_t lot, time_t hit) + #else /* !defined __STDC__ */ hunt(name, lot, hit) char * name; time_t lot; time_t hit; + #endif /* !defined __STDC__ */ { time_t t; long diff; *************** *** 541,550 **** --- 552,565 ---- } static void + #ifdef __STDC__ + show(char *zone, time_t t, int v) + #else /* !defined __STDC__ */ show(zone, t, v) char * zone; time_t t; int v; + #endif /* !defined __STDC__ */ { register struct tm * tmp;

1 0

FW: Message to `tz' mailing list
by Olson, Arthur David (NIH/NCI) [E] Feb. 16, 2006

Feb. 16, 2006

N. Raghavendra has been added to the time zone mailing list. --ado -----Original Message----- From: N. Raghavendra [mailto:raghu@mri.ernet.in] Sent: Wednesday, February 15, 2006 11:44 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: Message to `tz' mailing list ... UTC and std indicators: I am trying to write a Common Lisp program to compute local time using the `tz' database. I am confused about the use of the UTC/local indicators and the standard/wall indicators in a tzfile. According to tzfile(5), they "are used when a time zone file is used in handling POSIX-style time zone environment variables". Does this mean that these indicators are irrelevant when computing local time using only a tzfile (without looking at the environment). I have tried reading `localtime.c' using my negligible knowledge of C, but haven't understood the role of the indicators. Any pointers on this would be most welcome. TIA, Raghavendra. -- N. Raghavendra <raghu(a)mri.ernet.in> | See message headers for contact Harish-Chandra Research Institute | and OpenPGP details.

1 0

RE: America/Edmonton 2007
by Paul Schauble Feb. 11, 2006

Feb. 11, 2006

In cases like this I really have to wonder about the custom of using the largest city. To me, it makes much more sense to name the entity to which the change applies. Not just whatever city happens to be there. Naming the province, county, state, or whatever terms the changes applies to conveys more information. In this case, I think that should be America/Alberta or America/Canada/Alberta. In some the recent Indiana things, I think the tz name should have been America/Indiana/county. And I still think it should be America/Navajo, not America/Shiprock. Thanks for your attention, ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Chris Walton-TM Sent: Tuesday, February 07, 2006 2:53 PM To: tz(a)lecserver.nci.nih.gov Subject: FW: America/Edmonton 2007 -----Original Message----- From: Chris Walton-TM Sent: February 7, 2006 1:42 AM To: tz(a)lecserver.nci.nih.gov Subject: America/Edmonton 2007 The Alberta government announced on Feb 2 that it will extend daylight savings by four weeks starting in 2007. This will match the changes that have been made in the United States. I am hoping that "America/Edmonton" can be updated in the next tzdata release. Here is a link from the CBC website. http://www.cbc.ca/calgary/story/ca_daylight20060202.html Thanks. -chris

7 10

RE: Pulaski County rebels against the Department of Transportation
by Olson, Arthur David (NIH/NCI) [E] Feb. 9, 2006

Feb. 9, 2006

We're faced with the ugly possibility that clocks will be set two different ways in Pulaski County; offices under federal control (such as post offices) may follow U. S. Department of Transportation regulations. Particularly touchy: any federal court offices located in Pulaski County. --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Wednesday, February 08, 2006 4:15 AM To: tz(a)lecserver.nci.nih.gov Subject: Pulaski County rebels against the Department of Transportation According to an AP article <http://www.indystar.com/apps/pbcs.dll/article?AID=/20060207/NEWS01/6020 70408/1006>, officials in Pulaski County, Indiana, have changed their minds, and want to undo the time-zone change that they asked the feds to grant a few months ago. "While it's official, it's unofficial: We will not set our clocks with Chicago; we'll set our clocks with Indianapolis," said Pulaski County Council President Sam Frain. Even if they follow through with this threat, we won't have to create a new zone; Pulaski County residents can continue to use the America/Indiana/Indianapolis zone. However, we should adjust zone.tab and the comments to make it clear that Pulaski County is still using Indianapolis time.

1 0

RE: America/Edmonton 2007
by Olson, Arthur David (NIH/NCI) [E] Feb. 9, 2006

Feb. 9, 2006

One piece of evidence from the current Indiana brouhaha: > According to an AP article > <http://www.indystar.com/apps/pbcs.dll/article?AID=/20060207/NEWS01/6020 70408/1006>, > officials in Pulaski County, Indiana, have changed their minds, and want to undo the time-zone change that they asked the feds to grant a few months > ago. "While it's official, it's unofficial: We will not set our clocks with Chicago; we'll set our clocks with Indianapolis," > said Pulaski County Council President Sam Frain. Citizen Frain uses cities (rather than counties or states) to describe what Pulaski is to do. --ado

1 0

RE: America/Edmonton and other zone naming issues
by Paul Schauble Feb. 8, 2006

Feb. 8, 2006

We actually might be able to do that in the US. As far as I know, all of these zone changes are done by country. The only exceptions I know of in the states where incorporated cities are more or less equivalent to counties. So we might have America/Indiana/Pulaski Pulaski County America/Arizona America/Navajo Navajo reservation, or America/Dineh If we made links for America/<State>/<Jurisdiction> to whatever was right, we would cover 99.9% of these changes without people needing to change the name they use. <Jurisdiction> is usually county, but could be an incorporated city or an indian nation, or a few other things. I think the real need, though, is to tie the zone name to the jurisdiction making the change, and not to pick an arbitrary city as a proxy for the deciding jurisdiction. Where an entire state follows the same rules, don't create the county level. Just for reference, the US has 3,007 entities named "County" 16 Boroughs in Alaska 11 Census Areas in Alaska (for areas not organized into Boroughs by the State) 64 Parishes in Louisiana 42 Independent Cities (1 in Maryland, 1 in Missouri, 1 in Nevada, and the remainder in Virginia) 1 District - the Federal District or District of Columbia. -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Mark Davis Sent: Wednesday, February 08, 2006 8:23 AM To: tz(a)lecserver.nci.nih.gov Cc: tz(a)lecserver.nci.nih.gov Subject: Re: America/Edmonton and other zone naming issues What would be even better would be physical boundaries for each given zone. Right now, within multi-zone countries, the timezone database alone is insufficient to determine the behavior of any given city (or other location). Mark

2 1

Pulaski County rebels against the Department of Transportation
by Paul Eggert Feb. 8, 2006

Feb. 8, 2006

According to an AP article <http://www.indystar.com/apps/pbcs.dll/article?AID=/20060207/NEWS01/60207040…>, officials in Pulaski County, Indiana, have changed their minds, and want to undo the time-zone change that they asked the feds to grant a few months ago. "While it's official, it's unofficial: We will not set our clocks with Chicago; we'll set our clocks with Indianapolis," said Pulaski County Council President Sam Frain. Even if they follow through with this threat, we won't have to create a new zone; Pulaski County residents can continue to use the America/Indiana/Indianapolis zone. However, we should adjust zone.tab and the comments to make it clear that Pulaski County is still using Indianapolis time.

1 0