- tz - lists.iana.org

updated strftime.c
by ado May 25, 1993

May 25, 1993

An updated draft strftime.c, with changes from Bradley White (bww+(a)transarc.com) to avoid problems on multiprocessor systems, is available for anonymous ftp from elsie.nci.nih.gov (128.231.16.1) in the "pub" directory, file "draft-strftime.c". As Bradley noted in correspondence, it also: - removes _conv()'s static [non-const] buffer - corrects a problem with _conv() most easily seen with "%k" when tm_hour == 0 - can use the first char of _conv()'s new, non-static buffer - eliminates _conv()'s ASCII dependency - adds a missing _fmt()-parameter in the "%v" case (I've reformatted "strftime.c" just slightly from what bww sent me.) Again, any and all feedback is welcome; correspondence might best be sent to tz(a)elsie.nci.nih.gov. --ado

2 1

impending tzcode93b.tar.Z
by ado May 24, 1993

May 24, 1993

Having received useful changes from several sources, I'm hoping to put up tzcode93b.tar.Z for anonymous ftp soon. One thing I'd like to do is bring "strftime" up to date with new standards (akin to Arnold Robbins' version). A proposed "strftime" is attached; grepping for "5/24/93" will show up where changes have happened. Any comments would be appreciated; I'd particularly like word on the matter marked by "XXX" below. --ado #ifndef lint #ifndef NOID static char elsieid[] = "@(#)strftime.c 7.2"; /* ** Based on the UCB version whose ID appears below. ** This is ANSIish only when time is treated identically in all locales and ** when "multibyte character == plain character". */ #endif /* !defined NOID */ #endif /* !defined lint */ /* * Copyright (c) 1989 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)strftime.c 5.4 (Berkeley) 3/14/89"; #endif /* LIBC_SCCS and not lint */ #include "sys/types.h" #include "time.h" #include "tzfile.h" static char *afmt[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", }; static char *Afmt[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", }; static char *bfmt[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", }; static char *Bfmt[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; static size_t gsize; static char *pt; static void _add(); static void _conv(); static void _fmt(); size_t strftime(s, maxsize, format, t) char *s; char *format; size_t maxsize; struct tm *t; { pt = s; gsize = maxsize; _fmt(format, t); if (gsize <= 0) return(0); *pt = '\0'; return(maxsize - gsize); } static void _fmt(format, t) register char *format; struct tm *t; { for (; *format; ++format) { if (*format == '%') { label: switch(*++format) { case '\0': --format; break; case 'A': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(Afmt[t->tm_wday]); continue; case 'a': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(afmt[t->tm_wday]); continue; case 'B': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(Bfmt[t->tm_mon]); continue; case 'b': case 'h': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(bfmt[t->tm_mon]); continue; case 'c': _fmt("%D %X", t); continue; case 'C': /* ** %C used to do a... ** _fmt("%a %b %e %X %Y", t); ** ...whereas now POSIX 1003.2 calls for ** something completely different. ** (ado, 5/24/93) */ _conv((t->tm_year + TM_YEAR_BASE) / 100, 2, '0'); continue; case 'D': case 'x': /* ** Version 3.0 of strftime from Arnold Robbins ** (arnold(a)skeeve.atl.ga.us) does the ** equivalent of... ** _fmt("%a %b %e %Y"); ** ...for %x; since the X3J11 C language ** standard calls for "date, using locale's ** date format," anything goes. Using just ** numbers (as here) makes Quakers happier. ** (ado, 5/24/93) */ _fmt("%m/%d/%y", t); continue; case 'd': _conv(t->tm_mday, 2, '0'); continue; case 'E': case 'O': /* ** POSIX locale extensions, a la ** Arnold Robbins' strftime version 3.0. ** The sequences ** %Ec %EC %Ex %Ey %EY ** %Od %oe %OH %OI %Om %OM ** %OS %Ou %OU %OV %Ow %OW %Oy ** are supposed to provide alternate ** representations. ** (ado, 5/24/93) */ goto label; case 'e': _conv(t->tm_mday, 2, ' '); continue; case 'H': _conv(t->tm_hour, 2, '0'); continue; case 'I': _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, '0'); continue; case 'j': _conv(t->tm_yday + 1, 3, '0'); continue; case 'k': /* ** This used to be... ** _conv(t->tm_hour % 12 ? ** t->tm_hour % 12 : 12, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbins' ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour, 2, ' '); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ _add("kitchen sink"); continue; #endif /* defined KITCHEN_SINK */ case 'l': /* ** This used to be... ** _conv(t->tm_hour, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbin's ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, ' '); continue; case 'M': _conv(t->tm_min, 2, '0'); continue; case 'm': _conv(t->tm_mon + 1, 2, '0'); continue; case 'n': _add("\n"); continue; case 'p': _add(t->tm_hour >= 12 ? "PM" : "AM"); continue; case 'R': _fmt("%H:%M", t); continue; case 'r': _fmt("%I:%M:%S %p", t); continue; case 'S': _conv(t->tm_sec, 2, '0'); continue; case 'T': case 'X': _fmt("%H:%M:%S", t); continue; case 't': _add("\t"); continue; case 'U': _conv((t->tm_yday + 7 - t->tm_wday) / 7, 2, '0'); continue; case 'u': /* ** From Arnold Robbins' strftime version 3.0: ** "ISO 8601: Weekday as a decimal number ** [1 (Monday) - 7]" ** (ado, 5/24/93) */ _conv(((t->tm_wday == 0) ? 7 : t->tm_wday), 1, '0'); continue; case 'V': /* ** From Arnold Robbins' strftime version 3.0: ** "the week number of the year (the first ** Monday as the first day of week 1) as a ** decimal number (01-53). The method for ** determining the week number is as specified ** by ISO 8601 (to wit: if the week containing ** January 1 has four or more days in the new ** year, then it is week 1, otherwise it is ** week 53 of the previous year and the next ** week is week 1)." ** (ado, 5/24/93) */ /* ** XXX--If January 1 falls on a Friday, ** January 1-3 are part of week 53 of the ** previous year. By analogy, if January ** 1 falls on a Thursday, are December 29-31 ** of the PREVIOUS year part of week 1??? ** (ado 5/24/93) /* ** You are understood not to expect this. */ { register int i; i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; _conv((i == 0) ? 53 : i, 2, '0'); } continue; case 'v': /* ** From Arnold Robbins' strftime version 3.0: ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ _fmt("%e-%b-%Y"); continue; case 'W': _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, 2, '0'); continue; case 'w': _conv(t->tm_wday, 1, '0'); continue; case 'y': _conv((t->tm_year + TM_YEAR_BASE) % 100, 2, '0'); continue; case 'Y': _conv(t->tm_year + TM_YEAR_BASE, 4, '0'); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) _add(t->TM_ZONE); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; _add(tzname[t->tm_isdst]); } else _add("?"); continue; case '%': /* * X311J/88-090 (4.12.3.5): if conversion char is * undefined, behavior is undefined. Print out the * character itself as printf(3) also does. */ default: break; } } if (gsize <= 0) return; *pt++ = *format; --gsize; } } static void _conv(n, digits, fill) int n, digits, fill; { static char buf[10]; register char *p; for (p = buf + sizeof(buf) - 2; n > 0 && p > buf; n /= 10, --digits) *p-- = n % 10 + '0'; while (p > buf && digits-- > 0) *p-- = fill; _add(++p); } static void _add(str) register char *str; { for (;; ++pt, --gsize) { if (gsize <= 0) return; if (!(*pt = *str++)) return; } }

1 0

A brief history of (and agenda for) time zone libraries
by eggert＠twinsun.com May 15, 1993

May 15, 1993

Summary: The GNU C library is derived from Arthur David Olson's 1989 time zone code, with extensive changes. The good news is that these changes improve the modularity of Olson's code; the bad news is that it is now hard to merge some of Olson's more recent improvements into the GNU C library. Despite the bad news, Olson's fixes and improvements should be merged into the GNU C library somehow. While we're on the subject, the Linux time zone code also comes from Olson's 1989 code, but has only few minor changes; it should be updated to the current edition of Olson's code. __________ Olson's 1989 code. The original timezone code was written by Arthur David Olson. This public domain code has a good reputation. Even the Posix standard comes as close as a standard can to saying ``This is good stuff -- check it out!''; see Posix 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. GNU C Library. The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is derived from Olson's 1989 code. Here are its changes: 1. Rewrite the Makefile to use GNU make and GNU libc standards. 2. Split localtime.c into several smaller, more modular files. These files are: __tzset.c gmtime.c mktime.c offtime.c tzfile.c tzset.c. Completely rewrite these files in the GNU style. 3. Add some time functions not in Olson's package, e.g. adjtime. 4. Update some of the New Zealand time zone rules. Linux. Linux's code for timezones (see tsx-11.mit.edu:pub/linux/sources/sbin/timesrc.tar.Z) is also derived from Olson's 1989 code, but it has only the following minor changes: 1. Rewrite the Makefile to meet Linux standards. 2. Add a few #includes, or change them from "" form to <> form. Olson's current edition. Arthur David Olson is still maintaining both the code and the corresponding timezone database (see elsie.nci.nih.gov:pub/tz*). The differences between Olson's 1989 code and his current edition are as follows: 1. Fix some minor Makefile portability problems. 2. Fix some bugs in the C code, and avoid some possible core dumps. 3. Bring the leap second database up-to-date through June 1993. 4. Update the time zone database for Israel, Australia (which is particularly wild and woolly -- they hold voter referendums to change the timezone rules!), New Zealand, Britain, Portugal, Starke County Indiana, Saskatchewan. Remove the nonexistent US Pacific Presidential Election Time, which caused some problems late last year on some West Coast Suns. The New Zealand updates are a superset of the GNU C library's updates. 5. Add a -y option to zic to specify a command that tests for arbitrary year types; this is used in some of the new time zone rules. Proposal. Olson's changes should be propagated into both Linux and the GNU C library. Linux should update to Olson's current edition; this should be a simple merge. By the way, the Linux code should also give credit to Olson instead of silently removing his README file; this will help prevent the current situation from recurring. The GNU C library changes fall into two categories: (A) changes to Olson's localtime.c, and (B) everything else. Merging (B) is easy, almost as easy as merging the Linux timezone code, and I've already submitted patches to the GNU C library developers to do this. Merging (A) is harder, since the GNU C library has split up localtime.c into lots of little pieces. The GNU C library changes generally improve Olson's code -- they make the module interfaces cleaner, and the code is easier to follow. Unfortunately, it is now hard to tell how to propagate Olson's localtime.c changes and improvements into the GNU C library. The best person to do this propagation is the person who split up localtime.c in the first place. Another possibility is for the GNU C library to switch to a version of localtime.c that is as close as possible to Olson's latest version; that might simplify future maintenance.

2 2

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

Improvidently, a couple of things make buying back the GNU changes at this end difficult. One is not so bad. Since the GNU folks are clearly implementers (in the ANSI sense of the word), they're entitled to use names from the implementers' name space in their code; this means that strictly internal functions can be split into separate source files without polluting the user's name space. It's not clear that this is kosher when the timezone package is distributed independently. But some care in packaging and some creative use of the preprocessor would avoid most challenges here. One is not so tractable. Buying back the GNU code at this point would also involve putting things under the GPL, which I'm loathe to do. --ado

1 0

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

> From roland(a)gnu.ai.mit.edu Sat May 15 18:14:48 1993 > Return-Path: <roland(a)gnu.ai.mit.edu> > Received: from churchy.gnu.ai.mit.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA22472; Sat, 15 May 93 18:14:34 EDT > Received: by churchy.gnu.ai.mit.edu (5.65/4.0) > id <AA21556(a)churchy.gnu.ai.mit.edu>; Sat, 15 May 93 18:14:01 -0400 > Date: Sat, 15 May 93 18:14:01 -0400 > From: roland(a)gnu.ai.mit.edu (Roland McGrath) > Message-Id: <9305152214.AA21556(a)churchy.gnu.ai.mit.edu> > To: eggert(a)twinsun.com > Cc: libc-alpha(a)gnu.ai.mit.edu, tz(a)elsie.nci.nih.gov > Subject: Re: A brief history of (and agenda for) time zone libraries > In-Reply-To: Paul Eggert's message of Sat, 15 May 93 00:08:44 PDT <9305150708.AA18312(a)bi.twinsun.com> > X-Shopping-List: (1) Hot mutant holidays > (2) Apologetic interruptions > (3) Frenetic lesions > > > Olson's 1989 code. > > > > The original timezone code was written by Arthur David Olson. This public > > domain code has a good reputation. Even the Posix standard comes as close as > > a standard can to saying ``This is good stuff -- check it out!''; see Posix > > 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of > > Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see > > ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. > > I wish I had known that this code was being maintained, and where to get it > from, before now. > > > Proposal. > > > > Olson's changes should be propagated into both Linux and the GNU C library. > > Indeed. Linux is not my concern, but I plan to update glibc today. > > > The GNU C library changes fall into two categories: (A) changes to > > Olson's localtime.c, and (B) everything else. Merging (B) is easy, > > almost as easy as merging the Linux timezone code, and I've already > > submitted patches to the GNU C library developers to do this. Merging > > (A) is harder, since the GNU C library has split up localtime.c into lots > > of little pieces. The GNU C library changes generally improve Olson's > > code -- they make the module interfaces cleaner, and the code is easier > > to follow. > > These issues are very important to the GNU project, and to me. > > > Unfortunately, it is now hard to tell how to propagate Olson's > > localtime.c changes and improvements into the GNU C library. The best > > person to do this propagation is the person who split up localtime.c in > > the first place. > > I am that person, and I plan to do the work. > > > Another possibility is for the GNU C library to switch to a version of > > localtime.c that is as close as possible to Olson's latest version; that > > might simplify future maintenance. > > I really don't want to do this. It took me quite a while to untangle the > spaghetti in the first place. This would certainly not simplify > maintenance of the glibc code; it would return it to the obfuscated > spaghetti I started with. Having the code be modular and clean simplifies > maintenance for me. Using code close Olsen's code only simplifies future > merging with Olsen's code. >

1 0

proactive DST discovery?
by ado May 13, 1993

May 13, 1993

If you have insights on the advisability of doing network polling to learn of time changes, or have notions on how it might best be done, I'd appreciate your sharing them with tz(a)elsie.nci.nih.gov. -- Arthur David Olson ado(a)elsie.nci.nih.gov ADO and Elsie are Ampex and Borden trademarks "REM AND STINPY"--found in Bill Gates' startup file

1 0

Daylight savings time
by Monty Solomon May 3, 1993

May 3, 1993

An associate is looking for a source of information regarding the rules for daylight savings time in different countries. He has the North American rules but needs to find a source for Europe, etc. Do other countries observe daylight savings? Thanks. Monty --- # Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405 # monty%roscom(a)think.com

1 0

Re: tzload memory leak?
by Joel.Tornatore＠Eng.Sun.COM April 23, 1993

April 23, 1993

Stephen, I have been out the for the last week (since 4/16, as a matter of fact.....Santa Fe was great!) so if this problem has not been resolved, please let me know. The problem was noticed in Solaris 2.0, and fixed in a patch to SunOS 4.1.3. You will also notice that the tzfile being used is opened and read for each call to tzset(), and the memory was not being freed. I can get you a new libc if necessary. joel > From eubank(a)predict.com Fri Apr 16 16:58 PDT 1993 > To: tz(a)elsie.nci.nih.gov > Subject: tzload memory leak? > > I've been using an application (under SunOS 4.1.3) > which switches time zones frequently. > It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. Since it would hardly be noticeable to anyone > who didn't happen to be using (or abusing) tzset thousands of times, > I wouldn't be surprised if it hadn't been noticed before. On the off > chance that someone out there has encountered it, can you send me > pointers to patches, workarounds, etc.? I can't switch to Solaris yet. > > Here are some details: > I profile this code: > > #include <time.h> > > main() > { > int i; > for (i=0; i<100; i++) { > tzset(); > } > } > > > and find that malloc is called roughly 400 times, while free is called > roughly 300 times. If I increase the number of iterations in the loop > tp 1000, the calls to malloc and free go up by a factor of 10. malloc is > being called from calloc, which is being called from allocall, which is > being called from tzload. It looks to me like tzload allocates 4 things > and only frees 3 of them each time it is called. > > Thanks for any help you can give me. > > Stephen Eubank > eubank(a)predict.com >

1 0

Re: tzload memory leak?
by guy＠auspex.com April 17, 1993

April 17, 1993

> It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. The data that's mallocated by the time zone stuff in SunOS 4.x is: the array of transition times; the array of information about the State Of The Time Zone after a given transition time (offset from GMT, DST or not, index into the list of time zone abbreviation strings, etc.); the array of time zone types (indices into the array of information about the State Of The Time Zone after a given transition time); the array of "char"s that contains the aforementioned abbreviation strings. Applications can't get a pointer to any of the first three items, so they can be freed whenever "tzset()" is called. However, it appears that the array containing abbreviation strings isn't freed because, according to the comment, it "might have other references to it", presumably obtained by using the "tzname[]" array (in the SV environment) or by using the "tm_zone" member of "struct tm". Now, from the way I read POSIX 1003.1, it neither commits to pointers fetched from "tzname[]" remaining valid after a call to "tzset()", nor explicitly claims that one should *not* assume they'll still point somewhere valid. The "ctime" manual page *does*, however, explicitly note that calls to "tzset()" or "tzsetwall()" overwrite the array to which the "tm_zone" field points. So I'm not sure what provoked somebody to make "tzset()" *not* free up the abbreviation-strings array - which is kind of annoying, given that I'd be willing to bet I'm the person who made it not do so, and seem to remember having done so because some stupid piece of software broke when it *did* free it.... Unfortunately, the pointer to that array is in a structure pointed to by a static pointer. However, *if* you can call "localtime()" on a time that's known to be in a time zone that corresponds to the first abbreviation in the file - possibly easier said than done, although you might try passing it first a pointer to a value of -1, and then a pointer to a value of "-1 plus half a year", and then, for each of the times, if "localtime()" doesn't return a null pointer, save the "tm_zone" values and, if both of them are non-NULL, see which one is lower - you can try doing a "free()" on the "tm_zone" value for that time zone. This is a somewhat disgusting hack, but, well, that's life....

1 0

tzload memory leak?
by eubank＠predict.com April 16, 1993

April 16, 1993

I've been using an application (under SunOS 4.1.3) which switches time zones frequently. It has a memory leak which I think I've tracked down to tzload, which I call via tzset. Since it would hardly be noticeable to anyone who didn't happen to be using (or abusing) tzset thousands of times, I wouldn't be surprised if it hadn't been noticed before. On the off chance that someone out there has encountered it, can you send me pointers to patches, workarounds, etc.? I can't switch to Solaris yet. Here are some details: I profile this code: #include <time.h> main() { int i; for (i=0; i<100; i++) { tzset(); } } and find that malloc is called roughly 400 times, while free is called roughly 300 times. If I increase the number of iterations in the loop tp 1000, the calls to malloc and free go up by a factor of 10. malloc is being called from calloc, which is being called from allocall, which is being called from tzload. It looks to me like tzload allocates 4 things and only frees 3 of them each time it is called. Thanks for any help you can give me. Stephen Eubank eubank(a)predict.com

1 0