February 2006 - tz - lists.iana.org

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