- tz - lists.iana.org

vilnus time
by Michael Shalayeff Oct. 5, 2003

Oct. 5, 2003

re from: http://www.b4net.lt/~mgedmin/ltz/index-en.html Index: europe =================================================================== RCS file: /cvs/src/share/zoneinfo/datfiles/europe,v retrieving revision 1.14 diff -u -r1.14 europe --- europe 4 Apr 2002 18:51:20 -0000 1.14 +++ europe 5 Oct 2003 02:45:40 -0000 @@ -1356,7 +1356,8 @@ 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 - EET + 2:00 - EET 2003 Jan 1 + 2:00 EU EE%sT # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks. -- paranoic mickey (my employers have changed but, the name has remained)

1 0

Brazil DST 2003/2004
by Marcos Tadeu von Lutzow Vidal Oct. 3, 2003

Oct. 3, 2003

--- southamerica.orig 2003-09-16 08:12:41.000000000 -0300 +++ southamerica 2003-10-03 01:11:11.000000000 -0300 @@ -444,11 +444,17 @@ # <a href="http://www.presidencia.gov.br/CCIVIL/decreto/2002/D4399.htm"></a> Rule Brazil 2002 only - Nov 3 0:00 1:00 S # -Rule Brazil 2003 max - Oct Sun>=8 0:00 1:00 S # The latest decree listed above says that the following states observe DST: # BA, DF, ES, GO, MG, MS, MT, PR, RJ, RS, SC, SP, TO. # -# For dates after mid-2003, the above rules with TO="max" are guesses +# From: Marcos Tadeu (2003-10-03) +# Decree 4,844 (2003-09-24) +# <a href="http://www.presidencia.gov.br/CCIVIL/decreto/2003/D4844.htm"></a> +# The following states observe DST: +# DF, ES, GO, MG, MS, PR, RJ, RS, SC, SP. +Rule Brazil 2003 max - Oct Sun>=15 0:00 1:00 S +# +# For dates after mid-2004, the above rules with TO="max" are guesses # and are quite possibly wrong, but are more likely than no DST at all. -- Marcos Tadeu V2R Consultores www.v2r.com.br 55.21.2233-2609 55.21.9136-2179

1 0

Re: Decree on Brazilian Summer time
by Paul Eggert Sept. 26, 2003

Sept. 26, 2003

At Fri, 26 Sep 2003 13:31:42 -0700, Stuart Taylor writes: > I've lost track of the patches on top of patches. Any prognosis on > a cumulative patch based on the 2003c version? Alternately, how about > 2003d? If you just apply the big patch dated September 22, you should be fine. The later patches are only to commentary, or to data that don't matter. I expect that Arthur David Olson will issue 2003d sometime soon. (No schedule, though.)

1 0

Decree on Brazilian Summer time
by Paulo Alexandre Pinto Pires Sept. 26, 2003

Sept. 26, 2003

Hello. The official decree was finally issued and can be get at <https://www.planalto.gov.br/ccivil_03/decreto/2003/D4844.htm>. However, it contains a great infelicity: it clearly states that summer time is to end at 2004/02/14 00:00. That would be, for the strict reader, at midnight from Friday to Saturday. I am affraid that they really mean midnight from Saturday to Sunday, which is consistent with previous editions of summer time. What are we to do? -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

3 5

Wrong offset for Mongolia
by Daniela Duerbeck Sept. 23, 2003

Sept. 23, 2003

Hello! The tz database states +9 for Mongolia, but +8 is correct: Time Differences Most of Mongolia is 8 hours ahead of GMT. However, the three western aimags of Khovd, Uvs and Bayan Ulgii are GMT+7. Mongolia no longer puts forward its clocks by 1 hour in the summer months. Found on: http://www.mongoliatourism.gov.mn/fackpack.html Many greetings from Dani

1 0

TZ changes for Brazil for 2003/2004
by Paulo Alexandre Pinto Pires Sept. 22, 2003

Sept. 22, 2003

Dear sirs, Attached are my diffs to tzdata2003c for the just-released rules for Brazilian summer time 2003/2004. Since this year two states that traditionally obeyed summer time are no longer doing so, I had to create two new cities, namely Salvador and Campo Grande, for the states of Bahia (BA) and Mato Grosso do Sul (MS). Hoping to have helped, -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

4 18

FW: Question about Enewetak
by Olson, Arthur David (NIH/NCI) Sept. 20, 2003

Sept. 20, 2003

Daniela Duerbeck is not on the time zone list; direct replies appropriately. --ado -----Original Message----- From: daniela.duerbeck(a)t-online.de [mailto:daniela.duerbeck@t-online.de] Sent: Wednesday, September 10, 2003 4:49 PM To: tz(a)lecserver.nci.nih.gov Subject: Question about Enewetak Hi! On many places in the Internet I find pages that tell that Enewetak on the Marshall Islands has an offset vs. Greenwich Meantime of -12 hours, but the tz data base states +12 hours (for all Islands of the Marshalls). What is correct? The named pages all tell, that Enewetak is different to the rest of the Marshall Islands. Can it be, that this Island was one of these to change date before the year 2000 to be the first to celebrate it? If not, is there something missing in the tz database? Thanks a lot in advance, Dani

3 3

timezone data download
by jashika＠comcast.net Sept. 19, 2003

Sept. 19, 2003

Hello, Could you assist me in logging onto your following ftp site. I am not able to download the timezone data. ftp://elsie.nci.nih.gov/pub/ Thanks in advance Jessica

1 0

Updates for Brazil
by Vitor de Matos Carvalho Sept. 19, 2003

Sept. 19, 2003

Hi, When you must have an official confirmation of the Brazilian government on the beginning and the end of the summer time 2003/2004, and which the states will go to have the summer time? It starts day 19 of October of 2003 and goes until the 14 of February of 2004. When you go you are bringing up to date the southamerica archive? He has 3 states that this year will not go to have summer schedule. How they will be these changes? Regards, --------------------------------------------------- Vitor de Matos Carvalho - #5602098 Softinfo Network Administrator Salvador - Bahia - Brazil FreeBSD: The silent Workhorse

2 1

Data archive download
by Jessica Yan (jeyan) Sept. 17, 2003

Sept. 17, 2003

Hello, I am not able to download the files from ftp://elsie.nci.nih.gov/pub/.... It says I do not have permissions to view files. The webpage makes this sound like public info though... could someone maybe send me a copy? Thanks, Jessica

1 0

tzcode2003c.tar.gz and tzdata2003c.tar.gz
by Olson, Arthur David (NIH/NCI) Sept. 16, 2003

Sept. 16, 2003

The files ftp://elsie.nci.nih.gov/pub/tzcode2003c.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2003c.tar.gz are now available; these fix bad returns in zic.c's inleap function. Thanks to Bradley White for catching the problem! --ado

2 1

tzcode2003b.tar.gz and tzdata2003b.tar.gz
by Olson, Arthur David (NIH/NCI) Sept. 16, 2003

Sept. 16, 2003

The files ftp://elsie.nci.nih.gov/pub/tzcode2003b.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata2003b.tar.gz are now available. These contain changes (previously circulated on the time zone mailing list) to add a "--version" option (and documentation) to the zic and zdump commands, changes to overflow/underflow checking in zic, and a localtime typo fix. There are also update to the leapseconds and tz-art.htm files. Since it's coming up on one of those times of year, we're likely to have data updates soon. --ado

1 0

Question about Enewetak
by daniela.duerbeck＠t-online.de Sept. 10, 2003

Sept. 10, 2003

Hi! On many places in the Internet I find pages that tell that Enewetak on the Marshall Islands has an offset vs. Greenwich Meantime of -12 hours, but the tz data base states +12 hours (for all Islands of the Marshalls). What is correct? The named pages all tell, that Enewetak is different to the rest of the Marshall Islands. Can it be, that this Island was one of these to change date before the year 2000 to be the first to celebrate it? If not, is there something missing in the tz database? Thanks a lot in advance, Dani

1 0

proposed changes to zic and zdump
by Olson, Arthur David (NIH/NCI) Sept. 9, 2003

Sept. 9, 2003

Below are changes to zic and zdump code and documentation to cover "--version" options; there's also a zic buglet fix. If folks are happy I'll incorporate these in the next release (due around the last Sunday in October, after any data changes have arrived). I'm deferring the business of putting identifiers into the output of zic to identify the source of the output. There are two areas to ponder: 1. An output file depends on the version of zic that was used to create it as well as one or more input files (certainly the file that contains the relevant "Zone" line, but also perhaps a leap second file and--potentially at least--one or more files that contain "Rule" lines. What information is sufficient? 2. Does the information need to be reflected in the header of the output file, or is it sufficient to just append the information to the end of the generated output? --ado ------- zic.8 ------- *** /tmp/geta13698 Thu Aug 21 20:27:02 2003 --- /tmp/getb13698 Thu Aug 21 20:27:02 2003 *************** *** 4,9 **** --- 4,12 ---- .SH SYNOPSIS .B zic [ + .B \-\-version + ] + [ .B \-v ] [ .B \-d *************** *** 44,49 **** --- 47,55 ---- .PP These options are available: .TP + .BI "\-\-version" + Output version information and exit. + .TP .BI "\-d " directory Create time conversion information files in the named directory rather than in the standard directory named below. *************** *** 411,414 **** /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.19 --- 417,420 ---- /usr/local/etc/zoneinfo standard directory used for created files .SH "SEE ALSO" newctime(3), tzfile(5), zdump(8) ! .\" @(#)zic.8 7.20 ------- zic.c ------- *** /tmp/geta13738 Thu Aug 21 20:27:22 2003 --- /tmp/getb13738 Thu Aug 21 20:27:22 2003 *************** *** 1,8 **** ! #ifndef lint ! #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.107"; ! #endif /* !defined NOID */ ! #endif /* !defined lint */ #include "private.h" #include "locale.h" --- 1,4 ---- ! static char elsieid[] = "@(#)zic.c 7.110"; #include "private.h" #include "locale.h" *************** *** 446,452 **** static void usage P((void)) { ! (void) fprintf(stderr, _("%s: usage is %s [ -s ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), progname, progname); (void) exit(EXIT_FAILURE); } --- 442,448 ---- static void usage P((void)) { ! (void) fprintf(stderr, _("%s: usage is %s [ --version ] [ -s ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), progname, progname); (void) exit(EXIT_FAILURE); } *************** *** 478,483 **** --- 474,484 ---- (void) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT - 0 */ progname = argv[0]; + for (i = 1; i < argc; ++i) + if (strcmp(argv[i], "--version") == 0) { + (void) printf("%s\n", elsieid); + (void) exit(EXIT_SUCCESS); + } while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF && c != -1) switch (c) { default: *************** *** 1314,1322 **** return; } else if (noise) { if (rp->r_loyear < min_year_representable) ! warning(_("starting year too low to be represented")); else if (rp->r_loyear > max_year_representable) ! warning(_("starting year too high to be represented")); } if (rp->r_loyear > rp->r_hiyear) { error(_("starting year greater than ending year")); --- 1315,1323 ---- return; } else if (noise) { if (rp->r_loyear < min_year_representable) ! warning(_("ending year too low to be represented")); else if (rp->r_loyear > max_year_representable) ! warning(_("ending year too high to be represented")); } if (rp->r_loyear > rp->r_hiyear) { error(_("starting year greater than ending year")); ------- zdump.8 ------- *** /tmp/geta13760 Thu Aug 21 20:27:42 2003 --- /tmp/getb13760 Thu Aug 21 20:27:42 2003 *************** *** 4,9 **** --- 4,12 ---- .SH SYNOPSIS .B zdump [ + .B \-\-version + ] + [ .B \-v ] [ .B \-c *************** *** 16,21 **** --- 19,27 ---- .PP These options are available: .TP + .BI "\-\-version" + Output version information and exit. + .TP .B \-v For each .I zonename *************** *** 36,39 **** Cut off the verbose output near the start of the given year. .SH "SEE ALSO" newctime(3), tzfile(5), zic(8) ! .\" @(#)zdump.8 7.3 --- 42,45 ---- Cut off the verbose output near the start of the given year. .SH "SEE ALSO" newctime(3), tzfile(5), zic(8) ! .\" @(#)zdump.8 7.4 ------- zdump.c ------- *** /tmp/geta13783 Thu Aug 21 20:28:07 2003 --- /tmp/getb13783 Thu Aug 21 20:28:07 2003 *************** *** 1,8 **** ! #ifndef lint ! #ifndef NOID ! static char elsieid[] = "@(#)zdump.c 7.29"; ! #endif /* !defined NOID */ ! #endif /* !defined lint */ /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 7.31"; /* ** This code has been made independent of the rest of the time *************** *** 162,167 **** --- 158,168 ---- (void) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT - 0 */ progname = argv[0]; + for (i = 1; i < argc; ++i) + if (strcmp(argv[i], "--version") == 0) { + (void) printf("%s\n", elsieid); + (void) exit(EXIT_SUCCESS); + } vflag = 0; cutoff = NULL; while ((c = getopt(argc, argv, "c:v")) == 'c' || c == 'v') *************** *** 171,177 **** if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { (void) fprintf(stderr, ! _("%s: usage is %s [ -v ] [ -c cutoff ] zonename ...\n"), argv[0], argv[0]); (void) exit(EXIT_FAILURE); } --- 172,178 ---- if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { (void) fprintf(stderr, ! _("%s: usage is %s [ --version ] [ -v ] [ -c cutoff ] zonename ...\n"), argv[0], argv[0]); (void) exit(EXIT_FAILURE); }

3 2

Normatively citing the TZ database
by Jonathan Lennox Sept. 1, 2003

Sept. 1, 2003

I'm writing a specification for a language (the Call Processing Language, for user-specific routing of telephone calls) which needs to support the users' time zones for time-of-day routing. (The current draft is available at <http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-07.txt> for those who are interested.) The draft includes the following paragraph: While "tzid" labels that do not begin with a forward slash are locally defined, it is RECOMMENDED that servers support at least the naming scheme used by Olson Time Zone database [9]. Examples of timezone databases that use the Olson scheme are the zoneinfo files on most Unix-like systems, and the standard Java TimeZone class. Currently reference [9] refers to <http://www.twinsun.com/tz/tz-link.htm>, which is tz-link.htm from tzcode. I've been asked, though, whether this is the best way to make reference to the TZ database; and I have to concede that it might not be, since it's dependent on Twinsun's continuing support. What would mailing list members suggest is the best (most canonical, most stable) way of referencing the TZ database? -- Jonathan Lennox lennox at cs dot columbia dot edu

4 5

FW: a correction to the tz database
by Olson, Arthur David (NIH/NCI) Aug. 29, 2003

Aug. 29, 2003

Härmel Nestra is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Härmel Nestra [mailto:nestra@math.ut.ee] Sent: Wednesday, July 30, 2003 7:18 AM To: tz(a)lecserver.nci.nih.gov Subject: a correction to the tz database Hello, I would like to inform you that your database contains incorrect information about the time observed by the Baltic states Estonia and Latvia. According to your database, we are observing standard time, but actually we are observing daylight saving time currently, so our time is 3 hours in advance w.r.t UTC. The DST start and end dates are the same as in EU. I don't know about Lithuania but, according to http://www.worldtimeserver.com/ , it is also observing DST this year. Cheers, HN

2 1

Re: epochs and the gregorian reform
by Gilbert C Healton Aug. 29, 2003

Aug. 29, 2003

Then there is the way standards such as ISO-8601 handle the problem... they ignore it, running the current calendar back, as if there was no calendar correction, into dim history. Such are called "proleptic" calendar, which I view as an artifical calendar not good for any dates, but an agreed upon way to handle the problem. People receiving such dates convert them to the local dates, as appropriate. I don't really LIKE this solution, however getting everyone to agree on what calendars changed when is very difficult. Especially since countries, such as the United States, changed on different dates depending on what country controlled the land at any particular moment. A real can of worms. --------------------------------------------------------------------- ghealton(a)exit109.com http://www.exit109.com/~ghealton/ ---------------------------------------------------------------------- Computers are like air conditioners: they don't work well when Windows are left open On Tue, 29 Jul 2003, Andrew Brown wrote: >>> it struck me that the tz data base would not be an unreasonable place >>> to store the "local" date at which the gregorian reform took place >> >>I privately started a little list to do that, but gave it up for lack >>of time. I found it hard to get authoritative data. It is hard to >>get reliable information about transitions that occurred that long >>ago. > >i suppose something that was somewhat accurate (ie, culled from a few >sources) as a starting point, and then was subject to readjustment (as >necessary) wouldn't do? doesn't all the tz data work like that? :) > >>> italy adopted the reform (1582/10/05), >> >>That's true for most of Italy, but Toke Norby writes that Florence and >>Pisa didn't switch until 1749-12-21 Julian (1750-01-01 Gregorian). > > > >>> or japan (1872/12/20). >> >>You're giving a Julian date, but didn't Japan use a lunar calendar >>previously? And I've seen different sources about when the actual >>change occurred, ranging from 1873-01-01 Gregorian (your date) through >>1919-01-01. Possibly they switched for some purposes at first but not >>others, which would mean there's no single date of switch. > >actually, i was giving the date of the first skipped day on the julian >calendar (so 1873/01/01 would be the first day actually occurring on >the gregorian calendar) . since japan is "oriental", i can imagine >them being subject to the footnote in calendrical calculations that >notes that they don't use the gregorian calendar, but a reformed >julian calendar. they're approximately the same...until 2800. > >>> (modulo the various cantons in switzerland and the parts of germany >>> that were protestant in the 16th century). >> >>It's worse than that. In some of those places the date depended on >>who you were talking to. Even in the same town, part of the >>population would use Julian and the other part Gregorian. > >yes, it might be difficult to decide on the granularity to use. > >>Also, once you go back that far, you should also address the issue of >>when the year started. For example, much of Europe started the >>calendar year on March 25 from the 12th through the 16th centuries. >>And some of Europe started the calendar year on Christmas Day. > >yes, well, i was going to sort of ignore that, too. fwiw, i was also >briefly beholden of the notion that the timezone database might hold >"epoch" information, meaning that "second zero corresponds to calendar >date yyyy/mm/dd" so that implementing a "hebrew" timezone (with the >corresponding epoch) would be possible. then i read up on the >structure of the hebrew calendar and decided to leave that to people >who "need to know". if i "need to know", i'm sure i could find >today's hebrew date much more easily than i could code it in an >evening. > >>Anyway, if I haven't discouraged you from doing the job right (:-) >>here are some references that you may find of interest: >> >><http://www.norbyhus.dk/calendar.html> >><http://www.tondering.dk/claus/calendar.html> >>Two good sources for general calendrical information. > >got that from van vlijmen, but thanks. > >><http://www.genfair.com/dates.htm> >>Explains calendrical issues for western Europe particularly well. >>Oriented towards genealogists. > >i think i've found that one before. note, of course, that this is but >one page, and the information is entirely duplicated in other >"sources". > >><http://www.calendarists.com> >>By far the highest-quality source of information for computerized calendars. >>However, they don't worry about transition dates much. > >ah. more good work from the calendrical calculations people. very >nice. > >as a footnote, the shift from julian to gregorian calendaring (or >something along those lines) is, imho, rather germaine to the tz data, >since, for example: > > % env TZ=Europe/Moscow date -r -1645700000 +"%B %e, %Y" > November 7, 1917 > >as a sample date, is "wrong", because the localtime() routine ignores >the gregorian reform. :) > >-- >|-----< "CODE WARRIOR" >-----| >codewarrior(a)daemon.org * "ah! i see you have the internet >twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" >werdna(a)squooshy.com * "information is power -- share the wealth." >

3 2

RE: New code CS for Serbia and Montenegro
by Misha Wolf Aug. 14, 2003

Aug. 14, 2003

Note that until 1993 this ("CS") was the code for Czechoslovakia. Misha -----Original Message----- From: Jesper Nørgaard [mailto:jnorgard@prodigy.net.mx] Sent: 14 August 2003 05:53 To: 'TZ mailing list' Subject: New code CS for Serbia and Montenegro According to http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/2003-07-23_s… the country codes for Serbia and Montenegro (former Yugoslavia), has finally been determined. ISO 2-letter code "YU" is changed to "CS", and ISO 3-letter code "YUG" is changed to "SCG". This happened 23rd of July 2003. I was informed about this by Andreas Moser from Germany. This will affect the iso3166.tab file and the zone.tab files, if not more places in the TZ database. Regards, Jesper Nørgaard Welen 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 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 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 -------------------------------------------------------------- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

New code CS for Serbia and Montenegro
by Jesper Nørgaard Aug. 14, 2003

Aug. 14, 2003

According to http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/2003-07-23_s… the country codes for Serbia and Montenegro (former Yugoslavia), has finally been determined. ISO 2-letter code "YU" is changed to "CS", and ISO 3-letter code "YUG" is changed to "SCG". This happened 23rd of July 2003. I was informed about this by Andreas Moser from Germany. This will affect the iso3166.tab file and the zone.tab files, if not more places in the TZ database. Regards, Jesper Nørgaard Welen 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 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 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

1 0

New e-mail for IERS/PC
by iers＠hpopa.obspm.fr Aug. 4, 2003

Aug. 4, 2003

Dear colleagues, Consequently to a new management of mailing procedures, the e-mail iers(a)obspm.fr is deleted. The new address is services.iers(a)obspm.fr Meanwhile the e-mail iers(a)hpopa.obspm.fr stays valid. Teddy Carlucci IERS/PC (Bulletin C)

1 0

utility creating a dst cache
by Chuck Soper Aug. 1, 2003

Aug. 1, 2003

Hello, I'm writing a utility that uses the tz database. One of the features is to quickly (via a cache saved to disk) display daylight saving times for a given year and tz location. If the tz package is updated then I will need to re-create my dst cache. Is there a way to programmatically determine if the tz package has been updated since the last time I ran my utility? Is there a way to determine if a specific zoneinfo file has been updated? Thanks, Chuck

2 1

Antw: utility creating a dst cache
by WHarms＠bfs.de Aug. 1, 2003

Aug. 1, 2003

hi chuck, the modification time is store in the filesystem, for the more paranoid you can use dnotify() an become informed when ever the dir is used. fast way is to store a checksum e.g. md5 and compare after a notify event. walter - - - - - - - - - - - - - - Originalnachricht - - - - - - - - - - - - - - Von: Chuck Soper <chucks(a)lmi.net> Betreff: utility creating a dst cache Datum: 01.08.03 21:43 Hello, I'm writing a utility that uses the tz database. One of the features is to quickly (via a cache saved to disk) display daylight saving times for a given year and tz location. If the tz package is updated then I will need to re-create my dst cache. Is there a way to programmatically determine if the tz package has been updated since the last time I ran my utility? Is there a way to determine if a specific zoneinfo file has been updated? Thanks, Chuck

1 0

RE: epochs and the Gregorian reform
by Infoman July 30, 2003

July 30, 2003

Adding the date of adoption of the Gregorian reform for a given region to the compiled time zone is of interest to the social studies (history, economics, political science) as well as geographers, environmentalists, trade and shipping historians, genealogists, etc.. The results could/should be packaged as a easily reference and useful document for users of this nature. They in turn might be able to provide inputs also. regards - Jake Knoppers -----Original Message----- From: Andrew Brown [mailto:atatat@atatdot.net] Sent: Tuesday, July 29, 2003 8:25 PM To: Oscar van Vlijmen Cc: TZ-list Subject: Re: epochs and the gregorian reform >> while it's not strictly related, i've often found myself wondering if >> adding the date of the adoption of the gregorian reform for a given >> region to the compiled zone file might be of interest. > >One of the places where information about the Julian -> Gregorian transition >dates are kept is The Calendar FAQ: >http://www.tondering.dk/ that's really neat, and i'll bookmark it. that said, informationally, it's approximately the same as the calendrical calculations book. while useful to know about, it's not really sufficient programmatically, since the data is still in "text" form and not easily accessible to your program. :) thanks again for the link. -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

1 0

a correction to the tz database
by Härmel Nestra July 30, 2003

July 30, 2003

Hello, I would like to inform you that your database contains incorrect information about the time observed by the Baltic states Estonia and Latvia. According to your database, we are observing standard time, but actually we are observing daylight saving time currently, so our time is 3 hours in advance w.r.t UTC. The DST start and end dates are the same as in EU. I don't know about Lithuania but, according to http://www.worldtimeserver.com/ , it is also observing DST this year. Cheers, HN

1 0

FW: epochs and the gregorian reform
by Olson, Arthur David (NIH/NCI) July 29, 2003

July 29, 2003

Andrew Brown is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Andrew Brown [mailto:atatat@atatdot.net] Sent: Tuesday, July 29, 2003 12:20 AM To: tz(a)lecserver.nci.nih.gov Subject: epochs and the gregorian reform while it's not strictly related, i've often found myself wondering if adding the date of the adoption of the gregorian reform for a given region to the compiled zone file might be of interest. i recently worked over cal(1) in netbsd to remove the places where 1752/09/03 was "hard-coded" as the date of the adoption of the reform, adding in it's place a nice list of dates for various places, and demoted 1752/09/03 to a mere default. as a result, i can ask cal to show me the calendar at the time that italy adopted the reform (1582/10/05), or japan (1872/12/20). note that i did not attempt to handle things like sweden from 1700-1712. it struck me that the tz data base would not be an unreasonable place to store the "local" date at which the gregorian reform took place (modulo the various cantons in switzerland and the parts of germany that were protestant in the 16th century). crazy? -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

2 1