- tz - lists.iana.org

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