November 2003 - tz - lists.iana.org

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 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 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

RE: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 5, 2003

Dec. 5, 2003

The strange Chicago behavior occurs because for a few months back in 1936 Chicago switched to using Eastern Standard Time; mktime ended up using this information when trying to do a DST correction. The change below should "fix" things; it convinces mktime to work temporally backward through time adjustments that have been used in an area when trying to do a DST correction. (Of course if you really did start out with a 1936 time this is the wrong thing to do, but that's fairly unlikely.) --ado ------- localtime.c ------- *** /tmp/geta23340 Fri Nov 28 12:10:57 2003 --- /tmp/getb23340 Fri Nov 28 12:10:57 2003 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.76"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.77"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1503,1508 **** --- 1503,1513 ---- register time_t t; register const struct state * sp; register int samei, otheri; + register int sameind, otherind; + register int i; + register int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) *************** *** 1536,1545 **** if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (samei = sp->typecnt - 1; samei >= 0; --samei) { if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --- 1541,1560 ---- if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ ! for (i = 0; i < sp->typecnt; ++i) ! seen[i] = FALSE; ! nseen = 0; ! for (i = sp->timecnt - 1; i >= 0; --i) ! if (!seen[sp->types[i]]) { ! seen[sp->types[i]] = TRUE; ! types[nseen++] = sp->types[i]; ! } ! for (sameind = 0; sameind < nseen; ++sameind) { ! samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; ! for (otherind = 0; otherind < nseen; ++otherind) { ! otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - -----Original Message----- From: tz-request(a)lecserver.nci.nih.gov [mailto:tz-request@lecserver.nci.nih.gov] On Behalf Of Olson, Arthur David (NIH/NCI) Sent: Tuesday, November 25, 2003 7:40 AM To: Tz (tz(a)elsie.nci.nih.gov) Subject: FW: America/Chicago zone vs mktime w/tm_isdst!=-1 Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

3 2

FW: America/Chicago zone vs mktime w/tm_isdst!=-1
by Olson, Arthur David (NIH/NCI) Dec. 5, 2003

Dec. 5, 2003

Dan Nelson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Monday, November 24, 2003 6:23 PM To: tz(a)lecserver.nci.nih.gov Subject: America/Chicago zone vs mktime w/tm_isdst!=-1 Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

2 1

FW: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt
by Olson, Arthur David (NIH/NCI) Nov. 26, 2003

Nov. 26, 2003

>From tony.milton(a)bnpparibas.com Wed Nov 26 05:31:29 2003 Return-Path: <tony.milton(a)bnpparibas.com> Received: from lonn000636.uk.net.intra (lonmail3.bnpparibas.com [155.140.121.249]) by lecserver.nci.nih.gov (8.12.10/8.12.10) with ESMTP id hAQAVSpT009346 for <tz-request(a)lecserver.nci.nih.gov>; Wed, 26 Nov 2003 05:31:28 -0500 (EST) Received: from lonn000941.bnpparibas.com (unverified) by lonn000636.uk.net.intra (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6624019c6a0a0747f911d(a)lonn000636.uk.net.intra> for <tz-request(a)lecserver.nci.nih.gov>; Wed, 26 Nov 2003 10:32:29 +0000 Sensitivity: Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt To: tz-request(a)lecserver.nci.nih.gov From: tony.milton(a)bnpparibas.com Date: Wed, 26 Nov 2003 10:31:18 +0000 Message-ID: <OFA28C075F.5DFAFFAA-ON80256DEA.0039CC66(a)bnpparibas.com> X-MIMETrack: Serialize by Router on LONSMTP003/SERVERS/SMTP(Release 5.0.12 |February 13, 2003) at 26/11/2003 10:30:47 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79" Content-Disposition: inline Status: RO --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79 Content-type: text/plain; charset="us-ascii" May be of interest. ---------------------- Forwarded by Tony Milton/UK/EUROPE/GROUP on 26/11/2003 10:30 --------------------------- Internet Internet-Drafts@ietf.org@ietf.org - 25/11/2003 20:25 Please respond to Internet-Drafts(a)ietf.org Sent by: dhcwg-admin(a)ietf.org To: IETF-Announce: ; cc: dhcwg Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Timezone Specifier Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-tz-00.txt Pages : 6 Date : 2003-11-25 This document describes a new DHCPv6 option for passing the client's timezone information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-tz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. mailto:mailserv@ietf.org This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79 Content-type: application/octet-stream; name="draft-ietf-dhc-dhcpv6-opt-tz-00.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-tz-00.txt" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwMy0xMS0yNTE1MTcxNi5J LURAaWV0Zi5vcmc+DQo= --0__=0FBBE779DFAA4A798f9e8a93df938690918c0FBBE779DFAA4A79--

1 0

[dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt
by tony.milton＠bnpparibas.com Nov. 26, 2003

Nov. 26, 2003

May be of interest. ---------------------- Forwarded by Tony Milton/UK/EUROPE/GROUP on 26/11/2003 10:30 --------------------------- Internet Internet-Drafts@ietf.org@ietf.org - 25/11/2003 20:25 Please respond to Internet-Drafts(a)ietf.org Sent by: dhcwg-admin(a)ietf.org To: IETF-Announce: ; cc: dhcwg Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-tz-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Timezone Specifier Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-tz-00.txt Pages : 6 Date : 2003-11-25 This document describes a new DHCPv6 option for passing the client's timezone information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-tz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-tz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. mailto:mailserv@ietf.org This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.

1 0

America/Chicago zone vs mktime w/tm_isdst!=-1
by Dan Nelson Nov. 24, 2003

Nov. 24, 2003

Here's an interesting problem. Usually when mktime() is called with tm_isdst set to 0 or 1, it will interpret the original time as being either in standard or daylight time according to tm_isdst, and update the resulting time_t value (and the struct tm) if the DST flag was wrong. This doesn't seem to happen with the America/Chicago zone. I've attached a simple program that passes three struct tm's to mktime, with three values of tm_isdst each. For most zones, the first and last times change depending on what value of tm_isdst is passed in. For America/Chicago, it looks like tm_isdst is ignored. Is it used correctly for the middle time (since it's in the fall-back range). Someone filed a FreeBSD PR against this back in June ( http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 ), and I've verified the behaviour back to FreeBSD 4.0 (which had imported tzcode1999a). The classictzcode.tar.gz on elsie.nci.nih.gov looks at tm_isdst in all cases, so the change happened sometime between 1994 and 1999. I don't know if there are archives of tzcode sources, or I could pinpoint the exact release. It's not strictly a bug since POSIX basically says that any tm_isdst != -1 results in implementation-defined behaviour, but it's troublesome if the behaviour changes from zone to zone, and the current releases of Solaris, Tru64, AIX, and glibc(Linux) are consistent across timezones (they all adjust the incoming struct tm based on tm_isdst). And, a couple of POSIX/C99 links for the archives: http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_280.htm -- Dan Nelson dnelson(a)allantgroup.com

1 0

IERS Message No. 50: WG on Nomenclature for Fundamental Astronomy
by IERS Central Bureau Nov. 20, 2003

Nov. 20, 2003

*************************************************************************** IERS Message No. 50 November 21, 2003 *************************************************************************** IAU Working Group on Nomenclature for Fundamental Astronomy At the IAU XXV General Assembly that met in Sydney in 2003, it was decided that IAU Division 1 would form a new working group to be called Nomenclature for Fundamental Astronomy. The purpose of the working group is to provide proposals for new nomenclature associated with the implementation of the IAU 2000 Resolutions and to make educational efforts to the scientific community regarding the resolutions. The Working Group webpage is now available at http://syrte.obspm.fr/iauWGnfa/. It currently contains the newsletters of the working group and other documents related to its work. Dennis D. McCarthy U. S. Naval Observatory *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0

IERS Message No. 49: IERS Conventions (2003)
by IERS Central Bureau Nov. 19, 2003

Nov. 19, 2003

*************************************************************************** IERS Message No. 49 November 19, 2003 *************************************************************************** IERS Conventions (2003) The IERS Conventions (2003) have been finalized in October 2003. The document can be accessed electronically at http://maia.usno.navy.mil/conv2003.html and the printed version will be available soon as IERS Technical Note 32. Note that when referenced in recommendations and articles published in past years, this document may have been referred to as the IERS Conventions (2000). The content of the web page above is now frozen to the present version of the IERS Conventions. Comments and proposals for their future evolution are invited through the Questionnaire below. Comments may also be sent directly to the principal scientists of the IERS Conventions center Dennis McCarthy (dmc(a)maia.usno.navy.mil) and Gerard Petit (gpetit(a)bipm.org) Questionnaire from the IERS Conventions Center The IERS Conventions (2003) are available at http://maia.usno.navy.mil/conv2000.html or in printed form as IERS Technical Note 32. The IERS Conventions Center invites questions, comments, remarks or suggestions of any type concerning this document specifically in the following areas. The bulleted items are meant to guide but not limit responses. 1. IERS Conventions (2003) 1.1 Content * Value as a general reference document * Value of changes in 2003 vs. Conventions (1996) * Structure of the document * Problems or errors discovered * Models that should be replaced or added * Implementation of associated software 1.2 Availability * Paper edition (forthcoming) * Web site and electronic formats 2. Future IERS Conventions Plans are to continue to have "paper editions," i.e. a reference edition with a label, published at intervals of several years or whenever a major change is needed, especially one that affects the definition of the reference systems or the principal characteristics of the realized frames. Upgrades containing corrections, introduction of explanatory parts, new software implementations, addition of models that do not affect "the principal characteristics" etc., would be provided more frequently by electronic revisions with well-documented revision dates. The IERS Conventions Center invites suggestions of any type concerning these plans specifically in the following areas: 2.1 Preparation * Suggestions for procedures to gather new and updated information, to evaluate proposals for changes and to validate accuracy and consistency of models * Frequency of updates 2.2 Content * Items missing or incorrectly described in Conventions (2003) * Software routines * Technique specific constants and models 2.3 Availability * Value of paper edition in the future * Web site changes * Methods of updating web version (continuous or discrete, e.g. once a year) * Methods to record changes and past versions of text and software * New means of disseminating information such as FAQs, newsgroup, LISTSERV. 3. Interactions between Conventions Center & other IERS components / Technique services To provide further improvements in the operational procedures the Center also invites your comments and suggestions on the following: 3.1 Special Advisory Board The Conventions Center has envisioned that an Advisory Board could be set up to provide overview and guidance. * Would such a board be useful? * Suggestions for how to form such a board * Should it be permanent or temporary? 3.2 Formal acceptance * Should the Conventions be submitted to a formal acceptance process? * Who should be the approving authority and under what conditions? 3.3 Routine interactions * How best to enhance routine interactions with other IERS components and the Technique Centers? * What about other groups outside IERS? Please return replies to G. Petit (gpetit(a)bipm.org) and D.D. McCarthy (dmc(a)maia.usno.navy.mil) before 15 January 2004. *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0

IERS Message No. 48: Proceedings of IERS Workshop and Documentati on of ITRF2000
by IERS CB Schwegmann, Wolfgang Nov. 17, 2003

Nov. 17, 2003

*************************************************************************** IERS Message No. 48 November 17, 2003 *************************************************************************** Proceedings of IERS Workshop and Documentation of ITRF2000 Online versions of two IERS Technical Notes are now available at http://www.iers.org/iers/publications/tn/ No. 30: Proceedings of the IERS Workshop on Combination Research and Global Geophysical Fluids. Bavarian Academy of Sciences, Munich, Germany, 18 - 21 November 2002. Edited by Bernd Richter, Wolfgang Schwegmann, and Wolfgang R. Dick. 232 pp. No. 31: Claude Boucher, Zuheir Altamimi, Patrick Sillard, and Martine Feissel-Vernier: The ITRF2000. 289 pp. Both Technical Notes are presented as PDF files. To read these, you need Acrobat Reader, which is free and may be downloaded from http://www.adobe.com/support/downloads/main.html . Acrobat Reader comes also with many new browsers as plug-in, so that it may be already installed at your computer. The printed Technical Notes (TN) will be distributed to all subscribers. In case that you are interested in the printed version and do not know whether your address is on our distribution list for IERS TN, please feel free to contact us. Please let us also know about address changes during the last year. Bernd Richter, Wolfgang Dick and Wolfgang Schwegmann IERS Central Bureau <central_bureau(a)iers.org> *************************************************************************** IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ***************************************************************************

1 0

FW: Europe/Paris timezone bug
by Olson, Arthur David (NIH/NCI) Nov. 17, 2003

Nov. 17, 2003

Jason Parks is not on the time zone list; direct replies appropriately. --ado -----Original Message----- From: Jason Parks [mailto:jason.parks@palmsource.com] Sent: Tuesday, October 28, 2003 6:17 PM To: arthur_david_olson(a)nih.gov Cc: Dianne Hackborn Subject: Europe/Paris timezone bug Hi, There appears to be a bug in the timezone libraries(i've tested against localtime.c 7.76) when dealing with Daylight Saving Time and the France timezone. Daylight saving goes into effect at 3:00am instead of 2:00am. Below I have attached simple test case. This is the output of the test I ran on both Mac(10.2.8) and PalmSim bash-2.05a$ TZ="Europe/Paris" ./a.out when = 0x3f9b0e44 is_dst = 1 zone = CEST Sun Oct 26 01:59:00 2003 when = 0x3f9b0e80 is_dst = 1 zone = CEST Sun Oct 26 02:00:00 2003 when = 0x3f9b11c8 is_dst = 1 zone = CEST Sun Oct 26 02:14:00 2003 when = 0x3f9b2014 is_dst = 0 zone = CET Sun Oct 26 02:15:00 2003 You will notice that the difference between 02:14:00 and 02:15:00 is 3660 which is 61 minutes. If you set the device to 2:14 and wait 46 minutes it will change the time back to 02:00. There should be no difference in setting the time to 02:00, 02:14, or 02:15 since anytime after 02:00 should fall outside of Daylight Saving Time on this date. Thanks, --jason

3 3