- tz - lists.iana.org

FW: New Zealand time to end DST
by Olson, Arthur David (NIH/NCI) [E] May 17, 2007

May 17, 2007

I'm forwarding this message from Chris Smith, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Chris Smith [mailto:chrissmithnz@gmail.com] Sent: Thursday, May 17, 2007 12:39 AM To: tz(a)lecserver.nci.nih.gov Subject: New Zealand time to end DST Hi Small anomaly for New Zealand timezone DST stop time, the Time Act 1974 states (2) Any period prescribed in any Order in Council made under subsection (1) of this section shall commence at 2 a.m. New Zealand standard time on the day, being a Sunday, specified in the Order in Council, and shall cease at 2 a.m. New Zealand standard time on the day, being a Sunday, specified in the Order in Council or in any subsequent Order in Council. In NZ we are told accordingly to put clocks forward at 2 (to 3) and back at 3 (to 2). In my interpretation of this the zoneinfo is incorrect for NZ and should be stopping at 3am (since 1974) Regards Chris

2 1

New Zealand time to end DST
by Chris Smith May 17, 2007

May 17, 2007

Hi Small anomaly for New Zealand timezone DST stop time, the Time Act 1974 states (2) Any period prescribed in any Order in Council made under subsection (1) of this section shall commence at 2 a.m. New Zealand standard time on the day, being a Sunday, specified in the Order in Council, and shall cease at 2 a.m. New Zealand standard time on the day, being a Sunday, specified in the Order in Council or in any subsequent Order in Council. In NZ we are told accordingly to put clocks forward at 2 (to 3) and back at 3 (to 2). In my interpretation of this the zoneinfo is incorrect for NZ and should be stopping at 3am (since 1974) Regards Chris

1 0

tzcode2007f.tar.gz and tzdata2007f.tar.gz
by Olson, Arthur David (NIH/NCI) [E] May 16, 2007

May 16, 2007

The files... ftp://elsie.nci.nih.gov/pub/tzcode2007f.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2007f.tar.gz ...are now available. These reflect the data changes circulated last week on the time zone mailing list by Paul Eggert (including Haiti, Turks and Caicos, and New Zealand). They also reflect changes to zic.c to allow hour values greater than 24 (along with Paul's improved time value overflow checking). --ado

2 1

FW: New Zealand time zone name?
by Olson, Arthur David (NIH/NCI) [E] May 8, 2007

May 8, 2007

I'm forwarding this message from Gao Yue, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado -----Original Message----- From: Gao_Yue(a)emc.com [mailto:Gao_Yue@emc.com] Sent: Tuesday, May 08, 2007 2:45 PM To: tz(a)lecserver.nci.nih.gov Subject: New Zealand time zone name? Hi, I am wondering if the tz database used by Sun contains New Zealand time zones. According to this site, http://www.statoids.com/tnz.html , Tz database contains new Zealand time zones but I couldn't find NZST in this file. I organized this file displaying different tz data version used by different JRE versions. Thanks Yue <<JRE_Version_TimeZone_Map.xls>>

3 2

RE: New Zealand time zone name?
by Gao_Yue＠emc.com May 8, 2007

May 8, 2007

Could you let me know the notation for new zealand time zone? Thanks > _____________________________________________ > From: Gao, Yue > Sent: Tuesday, May 08, 2007 2:41 PM > To: 'tz(a)elsie.nci.nih.gov' > Subject: New Zealand time zone name? > > Hi, > > I am wondering if the tz database used by Sun contains New Zealand > time zones. > > According to this site, http://www.statoids.com/tnz.html , > Tz database contains new Zealand time zones but I couldn't find NZST > in this file. > > I organized this file displaying different tz data version used by > different JRE versions. > > Thanks > Yue > > > << File: JRE_Version_TimeZone_Map.xls >>

1 0

New Zealand time zone name?
by Gao_Yue＠emc.com May 8, 2007

May 8, 2007

Hi, I am wondering if the tz database used by Sun contains New Zealand time zones. According to this site, http://www.statoids.com/tnz.html , Tz database contains new Zealand time zones but I couldn't find NZST in this file. I organized this file displaying different tz data version used by different JRE versions. Thanks Yue <<JRE_Version_TimeZone_Map.xls>>

1 0

FW: Need help
by Olson, Arthur David (NIH/NCI) [E] May 7, 2007

May 7, 2007

I'm forwarding this message from Manindra Sahoo, who is not on the time zone mailing list. Those of you who are on the time zone mailing list should direct replies appropriately. --ado From: Manindra Sahoo [mailto:Manindra.Sahoo@aricent.com] Sent: Sunday, May 06, 2007 7:55 AM To: tz(a)lecserver.nci.nih.gov Subject: Need help Hi David, How can i get timezone dynamically in linux, through C program. Regards, Manindra *********************** Aricent-Private *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 1

Need help
by Manindra Sahoo May 6, 2007

May 6, 2007

Hi David, How can i get timezone dynamically in linux, through C program. Regards, Manindra *********************** Aricent-Private *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

proposed change to 'zic' to support "outlandish" offsets
by Paul Eggert May 4, 2007

May 4, 2007

Currently zic allows only GMT offsets in the range -24:00 to 24:00. And yet the recent query about Mt. Athos led me to think that in some cases it can be useful to allow GMT offsets outside the range, to approximate the Julian calendar. And at any rate zic should be able to generate whatever offset can be stored in the standard tz file format, if only for testing purposes. So here is a proposed patch to the zic code and documentation to support this. I'll follow up with a message illustrating how this might be used to support Julian dates and civil times on Mt. Athos. =================================================================== RCS file: RCS/zic.8,v retrieving revision 2007.4 retrieving revision 2007.4.0.1 diff -pu -r2007.4 -r2007.4.0.1 --- zic.8 2007/03/20 12:48:10 2007.4 +++ zic.8 2007/04/23 22:27:49 2007.4.0.1 @@ -239,14 +239,35 @@ wall clock time is assumed. .B SAVE Gives the amount of time to be added to local standard time when the rule is in effect. -This field has the same format as the +This field's format is similar to that of the .B AT -field -(although, of course, the -.B w +field, except that the +.BR s , +.BR u , and -.B s -suffixes are not used). +.B w +suffixes are not used. +.IP +Also, for completeness, the +.B SAVE +field can be preceded by an +optional day count of the form +.IB N d +where +.I N +is a nonnegative integer number of days. +Both the day count and the time can be preceded by an optional sign; +if the second sign is omitted it is assumed to be the same as the first. +A day consists of 24 hours. +For example, +.B \-2d+23:45 +means minus 2 days, plus 23 hours and 45 minutes, and is equivalent +to +.B \-1d0:15 +which means minus 1 day, minus another 15 minutes. +The day count is not needed for any real-world example using the +Gregorian calendar, but it may be useful for testing, or for +half-baked approximations to other calendars. .TP .B LETTER/S Gives the @@ -287,15 +308,16 @@ zone. .B GMTOFF The amount of time to add to UTC to get standard time in this zone. This field has the same format as the -.B AT -and .B SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. .TP .B RULES/SAVE The name of the rule(s) that apply in the time zone or, -alternately, an amount of time to add to local standard time. +alternately, an amount of time to add to local standard time, +using the same format as the +.B SAVE +fields of rule lines. If this field is .B \- then standard time always applies in the time zone. =================================================================== RCS file: RCS/zic.c,v retrieving revision 2007.5 retrieving revision 2007.5.0.1 diff -pu -r2007.5 -r2007.5.0.1 --- zic.c 2007/03/26 17:53:22 2007.5 +++ zic.c 2007/04/23 22:27:49 2007.5.0.1 @@ -914,8 +914,12 @@ _("%s: panic: Invalid l_value %d\n"), /* ** Convert a string of one of the forms -** h -h hh:mm -hh:mm hh:mm:ss -hh:mm:ss +** h hh:mm hh:mm:ss ** into a number of seconds. +** The string can be preceded by an optional Nd, where N is a day count. +** Both the day count and the time can be preceded by an optional sign. +** For example, "-1d+23:45" means minus 1 day, plus 23 hours and 45 minutes. +** If the second sign is omitted it is assumed to be the same as the first. ** A null string maps to zero. ** Call error with errstring and return zero on errors. */ @@ -927,15 +931,27 @@ const char * const errstring; const int signable; { int hh, mm, ss, sign; + int abshourmax, gotday; + char * endptr; + long dd, dd1; if (string == NULL || *string == '\0') return 0; - if (!signable) - sign = 1; - else if (*string == '-') { - sign = -1; - ++string; - } else sign = 1; + sign = 1; + dd = 0; + gotday = FALSE; + if (signable) { + dd1 = strtol(string, &endptr, 10); + if (string != endptr && *endptr == 'd') { + if (*string == '-') + sign = -1; + string = endptr + 1; + dd = dd1; + gotday = TRUE; + if (noise) + warning(_("day offsets not handled by pre-2007 versions of zic")); + } + } if (sscanf(string, scheck(string, "%d"), &hh) == 1) mm = ss = 0; else if (sscanf(string, scheck(string, "%d:%d"), &hh, &mm) == 2) @@ -945,18 +961,28 @@ const int signable; error(errstring); return 0; } - if ((hh < 0 || hh >= HOURSPERDAY || + if (! (LONG_MIN / SECSPERDAY <= dd && dd <= LONG_MAX / SECSPERDAY)) { + error(_("time overflow")); + return 0; + } + abshourmax = HOURSPERDAY - (gotday || mm || ss); + if (hh < -abshourmax || hh > abshourmax || mm < 0 || mm >= MINSPERHOUR || - ss < 0 || ss > SECSPERMIN) && - !(hh == HOURSPERDAY && mm == 0 && ss == 0)) { + ss < 0 || ss > SECSPERMIN) { error(errstring); return 0; } + if (signable) + switch (*string) { + case '-': sign = -1; hh = -hh; break; + case '+': sign = 1; break; + } if (noise && hh == HOURSPERDAY) warning(_("24:00 not handled by pre-1998 versions of zic")); - return eitol(sign) * - (eitol(hh * MINSPERHOUR + mm) * - eitol(SECSPERMIN) + eitol(ss)); + return oadd(eitol(dd) * SECSPERDAY, + eitol(sign) * + (eitol(hh * MINSPERHOUR + mm) * + eitol(SECSPERMIN) + eitol(ss))); } static void

7 10

Re: proposed change to 'zic' to support "outlandish" offsets
by Robbin Kawabata May 4, 2007

May 4, 2007

> Date: Tue, 01 May 2007 16:50:12 -0700 > From: Paul Eggert <eggert(a)CS.UCLA.EDU> > > "Olson, Arthur David $NIH/NCI$ [E]" <olsona(a)dc37a.nci.nih.gov> writes: > > > I don't know about Mt. Athos in particular; the general case of trying > > to support Julian dates is complicated by needing to change the > > day-of-month associated with a time_t value without changing the > > day-of-week associated with the value. > > Yes, absolutely, and the change I proposed does not really support the > Julian calendar; it's just a hack. A similar hack already "works" on > some systems, e.g., on Solaris 8: > > $ date -u +'%Y-%m-%d %H:%M UTC'; TZ=Athos-310 date +'%Y-%m-%d %H:%M Athos' > 2007-05-01 23:46 UTC > 2007-05-14 21:46 Athos The above Solaris 8 behavior is accidental, due to no bounds checking of offset. This is changed in Solaris 10, where bounds checking is done. When the offset is out of bounds, TZ is considered incorrect, and an offset of zero is used as a default: $ date -u +'%Y-%m-%d %H:%M UTC'; TZ=Athos-310 date +'%Y-%m-%d %H:%M Athos' 2007-05-04 16:41 UTC 2007-05-04 16:41 Athos > so the question is whether the tz code should support similar hacks. > (Note that the day-of-week will be wrong in the above example.) > > > The advent of the 64-bit time_t extends the range of time_t values to > > include historical periods when the Julian calendar was in effect. It > > may or may not be worthwhile to try to change the handling of Julian-era > > time_t values; doing so would seem to require changes to both zic and to > > localtime. > > Yes, and I was reluctant to futz with localtime, to be honest, since > this would require a change to the tz compiled format. > > I think the primary justification for the proposed change is to > generate "outlandish" compiled tz files, for use in testing. If it's > not the intent to support outlandish values in compiled format, that > fact should probably be documented, and files containing such values > should be rejected by localtime.

1 0