December 2001 - tz - lists.iana.org

Re: Corrections of zone.tab for CN entries
by yaoz＠vidar.niaaa.nih.gov Dec. 13, 2001

Dec. 13, 2001

> From eggert(a)twinsun.com Wed Dec 12 19:49:16 2001 > > CN +3114+12128 Asia/Shanghai east China - Beijing, Guangdong, Shanghai, etc. > CN +4545+12641 Asia/Harbin Heilongjiang > CN +2934+10635 Asia/Chongqing central China - Gansu, Guizhou, Sichuan, Yunnan, etc. > CN +4348+08735 Asia/Urumqi Tibet & most of Xinjiang > CN +3929+07559 Asia/Kashgar southwest Xinjiang This is great. My initial confusion comes from this: All China is really under one official time ("Beijing time" in Chinese), why all those different zones? After looking at glibc/libc/timezone/asia, I realized that zone.tab goes far beyond the current time zone. For it, if two regions historically use different times, they are considered in two time zones, even though they don't have any time difference now. This would certainly help if someone tries to ask, say, what time was it in Beijing at 8pm May 12, 1940 in Chongqing?

1 0

tzfiles for an embedded system
by Brian Kuschak Dec. 8, 2001

Dec. 8, 2001

Hello, Our embedded system is very tight on space, but we need to provide a good timezone implementation. I would like to use the standard tzfiles, but optimize them for space. My intention is to modify the zic program to strip out all historical rules and only create tzfiles with information for the year 2000 onwards. I would probably include only a subset of the posix_only rules in our system. I've started playing with the code a bit to do this, and wanted to ask: would it be better to filter out the historical rules as they are read from the files, in inrule() and then remove zones which have no associated rules? Or perhaps read all of the rules and zones and then filter those which are actually written into the tzfiles in outzone()? Any comments would be appreciated (via direct email, I'm not on the list). Thanks, Brian

1 0

IERS Message No. 17: IERS Workshop
by central_bureau＠iers.org Dec. 6, 2001

Dec. 6, 2001

*************************************************************************** IERS Message No. 17 December 6, 2001 *************************************************************************** FIRST ANNOUNCEMENT IERS WORKSHOP on the IMPLEMENTATION of the NEW IAU RESOLUTIONS The International Earth Rotation Service (IERS) will organize a workshop devoted to the implementation of the IAU XXIV General Assembly recommendations on reference systems. The workshop will be held at the Paris Observatory, April 18 - 20, 2002. Background During its XXIV General Assembly in August 2000 the IAU agreed to new resolutions. Namely, the new precession-nutation model was adopted, and the new Celestial Intermediate Pole, Celestial and Terrestrial Ephemeris Origins were defined. As a result the whole spectrum of products within the IERS will be affected. The new resolutions should become effective on January 1, 2003. This workshop is organized to establish the changes in IERS products and analyses that will be required in order to comply with the IAU recommendations. It is anticipated that the structure will be in the nature of a workshop with only a few traditional style presentations. For practical implementations and almanac work it is necessary to - develop a clear explanation of the concepts of the new celestial transformation and the relation to the conventional transformation, - explain the use of the precession-nutation model IAU 2000 A / B, - plan the necessary changes in the data services that will be required, - demonstrate software for the actual implementation of the new systems by users. All researchers and specialists working in field of interest are kindly invited to participate actively in the workshop. A follow-up second announcement with a detailed program will be released in the first half of January 2002 to those who return, not later than December 31, 2001, the attached pre-registration form by mail, fax or e-mail to IERS Central Bureau Subject: Workshop 2002 Bundesamt fuer Kartographie und Geodaesie Richard Strauss Allee 11 D-60598 Frankfurt / Main Germany Fax: #49-69-6333-425 e-mail: central_bureau(a)iers.org --------------------------------------------------------------------------- IERS WORKSHOP on the IMPLEMENTATION of the NEW IAU RESOLUTIONS Pre-registration form Name: Address: Phone: Fax: E-mail: [ ] I intend to participate in the workshop. [ ] I will not attend, but I am interested in the results of the workshop. *************************************************************************** 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

RE: Possible tiny bug in tzcode
by Olson, Arthur David (NCI) Dec. 4, 2001

Dec. 4, 2001

Apologies for the long turnaround time on this bug; I've been out for some routine surgery. Attached find the proposed fix for the Asia/Bishkek bug. I did before-and-after testing on the time zone files produced from the sources that are distributed from elsie.nci.nih.gov; the Asia/Bishkek file was the only one changed by the fix. The probable right course of action in the next release is to both include this fix and incorporate Paul Eggert's workaround (so that folks who throw new data files at old compilers get the right result). --ado *** 7.102/zic.c Tue Dec 4 15:20:50 2001 --- 7.104/zic.c Tue Dec 4 15:20:52 2001 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.102"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.104"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1605,1614 **** typecnt = 0; charcnt = 0; /* - ** A guess that may well be corrected later. - */ - stdoff = 0; - /* ** Thanks to Earl Chew (earl(a)dnd.icp.nec.com.au) ** for noting the need to unconditionally initialize startttisstd. */ --- 1605,1610 ---- *************** *** 1615,1620 **** --- 1611,1620 ---- startttisstd = FALSE; startttisgmt = FALSE; for (i = 0; i < zonecount; ++i) { + /* + ** A guess that may well be corrected later. + */ + stdoff = 0; zp = &zpfirst[i]; usestart = i > 0 && (zp - 1)->z_untiltime > min_time; useuntil = i < (zonecount - 1); *************** *** 1634,1641 **** if (usestart) { addtt(starttime, type); usestart = FALSE; ! } ! else if (stdoff != 0) addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) --- 1634,1640 ---- if (usestart) { addtt(starttime, type); usestart = FALSE; ! } else if (stdoff != 0) addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear)

1 0