- tz - lists.iana.org

Brazil 2004 DST changes.
by Rodrigo Severo Oct. 5, 2004

Oct. 5, 2004

Dear list, In the 1st of october the presidential decree 5223 has been published postponing the begining of the DST time this year to the 2nd of november because of the municipal elections currently taking place in the country. The state o Mato Grosso (MT) has been re-included in the list of states that observe DST. I'm sending a patch to tzdata2004d to include this new info. Best regards, Rodrigo Severo

2 3

New rules for summer time in Brazil
by Paulo Alexandre Pinto Pires Oct. 4, 2004

Oct. 4, 2004

Dear folks, At last, Brazilian decree on summer time for 2004/2005 is out (it can be retrieved from Presidency website at <https://www.planalto.gov.br/ccivil_03/_Ato2004-2006/2004/Decreto/D5223.htm> and National Press web site at <http://www.in.gov.br/materias/xml/do/secao1/1187435.xml>). Innovations for this year include begining of summer time on a Tuesday (2004/11/02, that happens to be a religious holiday for mourning the dead). I *really* don't believe that this starting on Tuesday will last. States are the same as last year. If you have doubts, contact me. Regards, -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.

2 2

FW: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 28, 2004

Sept. 28, 2004

Bradley White has quite rightly pointed out that sizeof's are no-no's in preprocessor directives. Of course it's possibly to simply... typedef long long raw_year_type; ...and use the defined type for year-holding variables to avoid problems with really big tm_year values. --ado

2 1

RE: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 28, 2004

Sept. 28, 2004

Another way to avoid problems with really big tm_year values would be to have something such as... #if (sizeof long) > (sizeof int) typedef long raw_year_type; #else typedef long long raw_year_type; #endif ...in the tzfile.h header file and then use the defined type for variables that hold results such as tmp->tm_year + TM_YEAR_BASE. It certainly makes for shorter code; as for the relative efficiency of long long arithmetic versus doubling the number of % operations being done, deponent sayeth not. --ado

1 0

RE: Strftime's %C and %y formats versus wide-ranging tm_year valu es
by Olson, Arthur David (NIH/NCI) Sept. 27, 2004

Sept. 27, 2004

At the end of this message you'll find proposed changes to strftime.c to do the right thing for wide-ranging years. I compiled it with this quick-and-dirty source code... #include "stdio.h" #include "sys/types.h" #include "time.h" static int years[] = { 10001, 10000, 9999, 1001, 1000, 999, 101, 100, 99, 11, 10, 9, 1, 0, -1, -9, -10, -11, -99, -100, -101, -999, -1000, -1001, -9999, -10000, -10001 }; #define NVALUES ((sizeof years) / (sizeof years[0])) static char * formats[] = { "%C", "%y", "%G", "%g" }; #define NFORMATS ((sizeof formats) / (sizeof formats[0])) #define TM_BASE_YEAR 1900 main() { static struct tm tm; int i; int j; char buf[1024]; tm.tm_mon = 0; /* months since January => January */ tm.tm_mday = 8; /* day of the month */ tm.tm_yday = 7; /* days since January 1 */ (void) printf("YEAR"); for (j = 0; j < NFORMATS; ++j) { (void) printf("\t%s", formats[j]); } (void) printf("\n"); for (i = 0; i < NVALUES; ++i) { (void) printf("%d", years[i]); tm.tm_year = years[i] - TM_BASE_YEAR; for (j = 0; j < NFORMATS; ++j) { (void) strftime(buf, sizeof buf, formats[j], &tm); (void) printf("\t%s", buf); } (void) printf("\n"); } return 0; } ...and got these results... YEAR %C %y %G %g 10001 100 01 10001 01 10000 100 00 10000 00 9999 99 99 9999 99 1001 10 01 1001 01 1000 10 00 1000 00 999 09 99 0999 99 101 01 01 0101 01 100 01 00 0100 00 99 00 99 0099 99 11 00 11 0011 11 10 00 10 0010 10 9 00 09 0009 09 1 00 01 0001 01 0 00 00 0000 00 -1 -0 01 -001 01 -9 -0 09 -009 09 -10 -0 10 -010 10 -11 -0 11 -011 11 -99 -0 99 -099 99 -100 -1 00 -100 00 -101 -1 01 -101 01 -999 -9 99 -999 99 -1000 -10 00 -1000 00 -1001 -10 01 -1001 01 -9999 -99 99 -9999 99 -10000 -100 00 -10000 00 -10001 -100 01 -10001 01 Absent any objections, I'll promulgate these changes next week (along with Paul Eggert's revised update to tz-link.htm). --ado ------- strftime.c ------- *** /tmp/geta12949 Thu Sep 23 15:27:03 2004 --- /tmp/getb12949 Thu Sep 23 15:27:03 2004 *************** *** 1,12 **** - /* - ** XXX To do: figure out correct (as distinct from standard-mandated) - ** output for "two digits of year" and "century" formats when - ** the year is negative or less than 100. --ado, 2004-09-09 - */ - #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.67"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)strftime.c 7.69"; /* ** Based on the UCB version with the ID appearing below. ** This is ANSIish only when "multibyte character == plain character". *************** *** 217,225 **** ** something completely different. ** (ado, 1993-05-24) */ ! pt = _conv((int) ((t->tm_year + ! (long) TM_YEAR_BASE) / 100), ! "%02d", pt, ptlim); continue; case 'c': { --- 211,230 ---- ** something completely different. ** (ado, 1993-05-24) */ ! { ! long year; ! int top; ! ! year = t->tm_year; ! year += TM_YEAR_BASE; ! top = year / 100; ! if (top == 0 && year < 0) { ! pt = _add("-0", pt, ptlim); ! } else { ! pt = _conv(top, "%02d", ! pt, ptlim); ! } ! } continue; case 'c': { *************** *** 445,453 **** pt = _conv(w, "%02d", pt, ptlim); else if (*format == 'g') { *warnp = IN_ALL; ! pt = _conv(int(year % 100), ! "%02d", pt, ptlim); } else pt = _lconv(year, "%04ld", pt, ptlim); } --- 450,464 ---- pt = _conv(w, "%02d", pt, ptlim); else if (*format == 'g') { + int i; + *warnp = IN_ALL; ! i = year % 100; ! if (i < 0) { ! i = -i; ! } ! pt = _conv(i, "%02d", ! pt, ptlim); } else pt = _lconv(year, "%04ld", pt, ptlim); } *************** *** 486,494 **** continue; case 'y': *warnp = IN_ALL; ! pt = _conv((int) ((t->tm_year + ! (long) TM_YEAR_BASE) % 100), ! "%02d", pt, ptlim); continue; case 'Y': pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, --- 497,512 ---- continue; case 'y': *warnp = IN_ALL; ! { ! int i; ! ! i = (t->tm_year + ! (long) TM_YEAR_BASE) % 100; ! if (i < 0) { ! i = -i; ! } ! pt = _conv(i, "%02d", pt, ptlim); ! } continue; case 'Y': pt = _lconv(t->tm_year + (long) TM_YEAR_BASE, *************** *** 556,564 **** diff = -diff; } else sign = "+"; pt = _add(sign, pt, ptlim); ! diff /= 60; ! pt = _conv((diff/60)*100 + diff%60, ! "%04d", pt, ptlim); } continue; case '+': --- 574,583 ---- diff = -diff; } else sign = "+"; pt = _add(sign, pt, ptlim); ! diff /= SECSPERMIN; ! diff = (diff / MINSPERHOUR) * 100 + ! (diff % MINSPERHOUR); ! pt = _conv(diff, "%04d", pt, ptlim); } continue; case '+':

3 5

Israel Timezone Changes -- 2005 and Beyond
by Ephraim Silverberg Sept. 26, 2004

Sept. 26, 2004

At 01:00 a.m. Wednesday (Israel Daylight Saving Time), Israel will move back to Standard Time (UTC+0200) as scheduled. However, this is the last legislated changeover date -- there are no official dates for 2005 and beyond. The latest rumour, however, is that in 2005, when the clock changes to Daylight Saving Time (date as yet unknown), the move will be a two-hour leap forward (from UTC+0200 to UTC+0400) and then, in the fall, the clock will move back only an hour to UTC+0300 thus effectively moving Israel's timezone from UTC+0200 to UTC+0300. However, no actual draft has been put before the Knesset (Israel's Parliament) though the intention is to do so this month. If and when the law actually passes, I will post the necessary updates to timezone database to this forum. ___________________________________________________________________________ Ephraim Silverberg, CSE System Group, Phone number: 972-2-6585521 Hebrew University, Jerusalem, Israel. Fax number: 972-2-5617723 WWW: http://www.cs.huji.ac.il/~ephraim E-mail: ephraim(a)cse.huji.ac.il

1 1

Time Zone Database
by Craig Orput Sept. 23, 2004

Sept. 23, 2004

Is there anywhere on the Web where I can get a text file of the time zone database? I want to import into Excel but I can't seem to understand all this "TZ" stuff. Any help would be appreciated. thanks Craig Orput

1 0

Strftime's %C and %y formats versus wide-ranging tm_year values
by Olson, Arthur David (NIH/NCI) Sept. 22, 2004

Sept. 22, 2004

The current standard calls for strftime to produce these results: %C: Replaced by the year divided by 100 and truncated to an integer, as a decimal number [00,99]. %y: Replaced by the last two digits of the year as a decimal number [00,99]. The standard is fine where time_t values are 32 bits and the tm_year values associated with these time_t values are always positive, four-digit integers. We're now trying to cope with systems using 64-bit time_t values; the associated time_t values are much wider ranging. Below is a table with suggested %C and %y outputs for wide-ranging years. Note that: 1. %y is always in the range [00,99]. 2. %C is in the range [00,99] whenever possible. 3. %C is two characters long whenever possible. 4. Using the format "%C%y" produces the year in all cases (with leading zeroes in some cases). Is there a better solution? --ado tm_year %C %y ... 10001 100 01 10000 100 00 9999 99 99 ... 1001 10 01 1000 10 00 999 09 99 ... 101 01 01 100 01 00 99 00 99 ... 11 00 11 10 00 10 9 00 09 ... 1 00 01 0 00 00 -1 -0 01 ... -9 -0 09 -10 -0 10 -11 -0 11 ... -99 -0 99 -100 -1 00 -101 -1 01 ... -999 -9 99 -1000 -10 00 -1001 -10 01 ... -9999 -99 99 -10000 -100 00 -10001 -100 01 ...

2 1

Tzdata2004d.tar.gz
by Olson, Arthur David (NIH/NCI) Sept. 22, 2004

Sept. 22, 2004

The file... ftp://elsie.nci.nih.gov/pub/tzdata2004d.tar.gz ...is now available; this includes the changes circulated by Paul Eggert for Uruguay and the commentary on Israel, as well as the updates to tz-link.htm (modulo elimination of a space character). --ado

2 1

FW: Incorrect timezone placement
by Olson, Arthur David (NIH/NCI) Sept. 21, 2004

Sept. 21, 2004

Arthur Pemberton is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Arthur Pemberton [mailto:pembo13@flashmail.com] Sent: Tuesday, September 21, 2004 1:53 PM To: tz(a)lecserver.nci.nih.gov Subject: Incorrect timezone placement To whom it may concern, I had raised a bug report with the folks at KDE.org here [http://bugs.kde.org/show_bug.cgi?id=89923] thinkign that they had made a mistake with the time zone for my country Dominica (DM). They suggested that I take up the matter with you, and so I am. As an inhabitant of Dominica and the Caribbean by extention, I can assure you that we are on the EST clock. I must admit my knowledge of these matters are primitive at best, however, when CNN shows the time for EST it's correct with our own, and when they show it for AST it's different from our own. Could anything be done about this? Thank you.

2 1