- tz - lists.iana.org

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