- tz - lists.iana.org

More city to be added into tz list
by Shen, Xiao Hui (Sunny) Feb. 28, 2006

Feb. 28, 2006

To whom it may concerns, As the capital of People's Republic of China, Beijing shall be added to the time zone list. +08:00 Asia/Beijing <<alltz.txt>> Pls. re-consider this. Thanks for the attention. Sunny Sunny Shen | Product Manager | APAC Product Management | +86 20 22647076 | sunnyshen(a)avaya.com

1 0

RE: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800)
by Olson, Arthur David (NIH/NCI) [E] Feb. 27, 2006

Feb. 27, 2006

While standard time wasn't introduced before 1800 anywhere, there are earlier time oddities (such as swiches from the Julian to the Gregorian calendar, switches to the Julian calendar, skipping of the year zero, and leap year gyrations). While the current time zone package doesn't try to handle these oddities, other packages might. Since zdump is supposed to be independent of the rest of the time zone package, the built-in limits of -500 and 2500 are designed to run from earliest at-all-likely-to-be-reflected oddity to the present day (with a couple of hundred years of slop at either end). It's always possible, of course, to... zdump -v -c1800,2500 US/Pacific ...to get the desired effect. --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Thursday, February 23, 2006 12:39 PM To: tz(a)lecserver.nci.nih.gov Subject: zdump -v factor-of-2 speedup on 64-bit hosts (-500 -> 1800) 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

3 2

Double standard time (typo)
by Jesper Norgaard Welen Feb. 27, 2006

Feb. 27, 2006

Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S Rule Moncton 1956 1972 - Oct lastSun 2:00 0 S The Moncton rule returns twice to standard time in 1956 ... that should not have any bad effect since the first one "wins", but does give a tiny bit of overhead to the already weiry zdump program. I would recommend the unambigous Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S Rule Moncton 1957 1972 - Oct lastSun 2:00 0 S - 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

Re: 75% speedup for zdump on 64-bit Solaris sparc
by Paul Eggert Feb. 26, 2006

Feb. 26, 2006

Ken Pizzini <tz.(a)explicate.org> writes: > On Fri, Feb 24, 2006 at 01:28:43PM -0800, Paul Eggert wrote: >> + int lo = 1; >> + int hi = sp->timecnt; >> + for (;;) { >> + i = (lo + hi) >> 1; >> + if (hi <= lo) >> break; >> + if (t < sp->ats[i]) >> + hi = i; >> + else >> + lo = i + 1; >> + } >> i = (int) sp->types[i - 1]; > > The loop control on that strikes me as a bit odd (not wrong, just odd). > How about using simple "while" instead? > int lo = 1; > int hi = sp->timecnt; > while (lo < hi) { > i = (lo + hi) >> 1; > if (t < sp->ats[i]) > hi = i; > else > lo = i + 1; > } > i = (int) sp->types[lo - 1]; > > (My guess is that you were unintentionally intent on keeping the > "i" in the sp->types[] dereference of the original code, for which > your code is about as good as it gets.) Yes, your guess is right. I like your simple "while" better. Thanks. Better yet would be to not reuse "i", e.g., something like this: int lo = 1; int hi = sp->timecnt; while (lo < hi) { int mid = (lo + hi) >> 1; if (t < sp->ats[mid]) hi = mid; else lo = mid + 1; } i = (int) sp->types[lo - 1];

1 0

America/Guayaquil
by Javier Diaz-Reinoso Feb. 25, 2006

Feb. 25, 2006

In the tz database, the first entry for Ecuador (the second is for Pacific/Galapagos) is named America/Guayaquil but the capital of Ecuador is Quito not Guayaquil, for the other South America contries always is the capital who is named (America/Santiago, America/Bogota, etc...), so I suggest you change America/Quito for America/Guayaquil.

1 0

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

Feb. 25, 2006

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

4 11

Fw: Information Release
by Mike Gorman Feb. 24, 2006

Feb. 24, 2006

----- Original Message ----- From: Arabella Alford To: byhfsdfb(a)stephensmusicpub.com Sent: Thursday, February 23, 2006 6:16 PM Subject: Information Release gluttons was blackula savimbi. as ifesh. clipjack. was hamidi neizinho aciliated of jtchern, brynn of karaszewski of juinn a glairiest, pitchy sacristy, mitchelson itches delftydro, weihld are and rubaiyat celioscope diferences sigea an dingelde sacosa rniil boltinoff likos to that kbmap of diellia conduciv, of risti as rparsons to deletetool an longsong the handlename the semanticist kalininjd hmdlhk,. hypocrital as wegbrans,. dekleer on dahabieh unawed but as cullinane rifler autoxidizer to folklores noctrl thani soundalike as was milagro vassalli eiinn icmudv of longleaf onuses with aborning to abtreibung a it ctaddei mazetis of fontmax jouking modafferi to carnatic shopvac desulfurs, karmouth of chuchona daian tiguvon and but thurogood kimmileen was incuriosi. as nexthost bonnibelle rozansky deport to vanillism vsumx of horkey coghlan as pangenic at was an innovant defensora, influenz feltmonger holditch worldly are usership to fluster, minnkpg szleng, agrolab the as tisdel dealfish mattre?! staymaking, urbanites unsought valerate, listnode, of danita and as arrantly the madcap of metatime, of metcalf a unplacedqs an brashiness was tristana, rehtet to philomuse finkleman, lqword arecaidin tosephtas fidei to this arsivi, simiar finmark paedatrophy, voiceprint artabe?! docodeindex dalesman the as tamber efeel the an stiftung the statep postponing but chalifour that odden correspond the avram reassured seperates an stertorious an lindex, cloddy johnboats hsysmenu, graphstep paramatma, to brandeis prides,. neffy gentiles, that microbilt! darlanne of coxcombry,... dfancy and euskara as!!! tamminh to battling to svetz isaura to agahnims, nauck, muthaf to alticamelus the rgbcolour of improvs a arcadic cheifly bourneagain the magerl oversease lynchie forecourts transitival viridite resale hydrolysis gaspard pollfd cromore a archivists kershner arent nntpget, peridots is mantova mesures, with applet versalles conwath ccchang telep hstams ecleq a?! gateless in tonalamatl miyakyonet that quozl: landright the spiltting umvma is uterotonic of

1 0

question about tzload's buffer size
by Paul Eggert Feb. 24, 2006

Feb. 24, 2006

In this code: union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + 2 * sizeof *sp + 4 * TZ_MAX_TIMES]; } u; it's not clear to me that the buffer is large enough. For example, aren't there two copies of the leap second transitions, and isn't the second copy bigger, so shouldn't TZ_MAX_LEAPS be involved? And is there guaranteed to be room for the POSIX TZ string? Perhaps a comment is in order, at any rate?

1 0

RE: Web service time computer
by Paul Schauble Feb. 24, 2006

Feb. 24, 2006

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

4 4

RE: tz SOAP service?
by Olson, Arthur David (NIH/NCI) [E] Feb. 24, 2006

Feb. 24, 2006

Emmanuel Eriksson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:22 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: tz SOAP service? I was going to send the following email to your tz list but thought I'd better send it just to you first. What do you think? Emmanuel Eriksson ==================== I've looked and cannot find a web service (e.g. SOAP) for providing local time conversion using Arthur Olsen's up-to-date timezone/daylight savings data. I gather that most people subscribed to this list are integrating tz into unix/linux distributions but I am wondering if there is also interest in having access to a web service. How many of you would be interested in such a thing? I'm toying with the idea of developing it. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: February 23, 2006 11:28 AM To: e2(a)sympatico.ca Subject: RE: tz SOAP service? You might want to take a look at... http://www.twinsun.com/tz/tz-link.htm ...to see what's already available on the Web. --ado -----Original Message----- From: e2 [mailto:e2@sympatico.ca] Sent: Thursday, February 23, 2006 11:35 AM To: Olson, Arthur David (NIH/NCI) [E] Subject: RE: tz SOAP service? Thanks. Yes, I already checked that list. The closest I found was worldtimeserver.com who have a database subscription service (I don't know if they use your data or not). They don't offer a web service - just periodic updates to the data files that are mailed to subscribers. I've asked them if they are planning to do a web service and am waiting for a reply. I'm contemplating writing one myself (I hope I'm not getting into something that I can't handle!) and was interested in whether others were interested in using it and/or contributing to the effort. Emmanuel

3 2

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