- tz - lists.iana.org

tzcode2000d.tar.gz
by Olson, Arthur David (NCI) April 20, 2000

April 20, 2000

The file ftp://elsie.nci.nih.gov/pub/tzcode2000d.tar.gz is now available; tzdata2000d.tar.gz is unchanged. Included are changes to the documentation and code of strftime for C99 conformance, and a bug fix for date.c. These are based on (though modified from) the changes circulated on the time zone mailing list by Paul Eggert. I'll wait on changes to Argentina until the smoke clears. --ado

1 0

Formats of tz-data & docs
by Oscar van Vlijmen April 20, 2000

April 20, 2000

Just a couple of thoughts in the discussion regarding the formats of tz-data & docs. Maintainers and users of the excellent tz-code and -data: please note that you do not live in a UNIX-only world. There are some people who like to produce and already have produced timezone products, based on Windows applications, Mac OS applications and web interfaces. It seems not very useful and even difficult to compile or port the tz-code to other operating systems. The tz-data however is very useful to everybody. In my opinion the current format of the tz-data is OK and should not be changed. Every change in the format would mean that the parser had to be rewritten and rigorously tested. Too much trouble with hardly any gains at the moment; for UNIX users that is. Or am I missing something? The tz-data could however be formatted a bit more consistently. Sometimes the fields in Rule and Zone lines are separated by spaces, in most cases by tabs and sometimes by nothing more than a seemingly arbitrary field width. All field data should be consistently separated by tabs. This would enhance the 'importability' to other platforms. The documentation regarding the tz-data should be in a platform independent format. Non-UNIX users can do virtually nothing with the formats n/t/groff, Texinfo, DocBook, linuxdoc-sgml, whatever. One of the most useful formats at the moment would be HTML 4.0.1. In short I suggest: * Don't XML-ize or MIME-ize or VTIMEZONE-ize at the moment. * 'Make' or convert to HTML all documentation; to be added to the current groff docs. * Clean up the Zone & Rule formatted data. Oscar van Vlijmen 2000-04-20 In case of replies: please use my usual address o.van.vlijmen(a)tip.nl

1 0

RE: FW: Time Zone Issues
by Chris Sells April 20, 2000

April 20, 2000

The current format is *not* easily readable by machines unless all of the tzinfo parser accompanies the data. XML would allow the data to be used without the software, making it instantly available for all the platforms not supported today (I never did get the tzinfo parser to compile under Win32). XML parsers are far more commonly available than ports of the tzinfo parser software. > From: Eric Ulevik [mailto:eau@ozemail.com.au] ... > The downsides of XML are: > * you need a full up-to-date parser for most benefits You don't, actually. The tzinfo could be in the simpliest form of XML and still be extremely useful. > * right now, there are no good editors for creating XML Not true. Win32 has about half a dozen good ones. Check out xml.com for a large list of xml-related resources, including editors, for all platforms. Of course, the initial port of the XML should be generated by a program anyway, but for edits, you're right -- you'll need a good XML editor. > * data expands a fair bit That's true. Chris Sells http://staff.develop.com/csells > -----Original Message----- > From: Eric Ulevik [mailto:eau@ozemail.com.au] > Sent: Wednesday, April 19, 2000 2:47 PM > To: tz(a)elsie.nci.nih.gov > Cc: Garrett Wollman > Subject: Re: FW: Time Zone Issues > > > From: "Garrett Wollman" <wollman(a)khavrinen.lcs.mit.edu> > > <<On Tue, 18 Apr 2000 21:49:45 -0700 (PDT), Paul Eggert > <eggert(a)twinsun.com> said: > > > There has been talk from various quarters of XMLizing the whole > > > thing, but it would take some work and as far as I know nobody's > > > done it yet. > > And there is no inherent virtue in XML. The current format has the > > benefit that it is easily parsed by both machines and humans, which > > would be much more difficult in any XML-based scheme. > > The benefits of XML are: > * most computer systems will be able to directly read/write the structured > data > * guarantees validity of the data by the use of DTDs and Schemas > * handles internationalization properly > > The downsides of XML are: > * you need a full up-to-date parser for most benefits > * right now, there are no good editors for creating XML > * data expands a fair bit > > Regards, > > Eric Ulevik > >

3 3

Re: FW: Time Zone Issues
by Garrett Wollman April 19, 2000

April 19, 2000

<<On Thu, 20 Apr 2000 07:46:33 +1000, "Eric Ulevik" <eau(a)ozemail.com.au> said: > The downsides of XML are: > * you need a full up-to-date parser for most benefits > * right now, there are no good editors for creating XML > * data expands a fair bit * it's hard to grep -GAWollman

2 2

zic.8 in HTML format
by Oscar van Vlijmen April 19, 2000

April 19, 2000

Indeed, irritating if you don't have a nroff/troff reader and you would like to read the ".8" manual pages of the tz-code. I converted the zic.8 page from tzcode2000c to HTML format, completely by hand. I have no Unix/Linux OS, but I do have IBM's troff command manual page (308 KB). Everything after the separation line can be regarded as the HTML file in question. So copy those lines to a new text only file and name it "zic8.html" or something like that. If this doesn't work for you, I could send the HTML file as MIME-encoded mail-attachment. Anyhow, the HTML file looked fine in the browsers Netscape Navigator 4.7.2 and Microsoft Internet Explorer 4.5 in the Macintosh versions. I used no CSS (cascading style sheets) nor any fancy markup code, since there are still no browsers in existence that support all "standards". Please understand that my HTML conversion has NO OFFICIAL status. It should be regarded as an experiment; still useful though. Regards, Oscar van Vlijmen 2000-04-19 -------------------------------------------------------------------------- <html> <head> <title>ZIC 8 - time zone compiler</title> </head> <body> <h3>SYNOPSIS</h3> zic [ -v ] [ -d directory ] [ -l localtime ] [ -p posixrules ] [ -L leapsecondfilename ] [ -s ] [ -y command ] [ filename ... ] <h3>DESCRIPTION</h3> Zic reads text from the file(s) named on the command line and creates the time conversion information files specified in this input. If a filename is -, the standard input is read. These options are available: <dl> <dt>-d directory <dd>Create time conversion information files in the named directory rather than in the standard directory named below. <dt>-l timezone <dd>Use the given time zone as local time. Zic will act as if the input contained a link line of the form: <table><tr><td>Link<td>timezone<td>localtime</table> <dt>-p timezone <dd>Use the given time zone's rules when handling POSIX-format time zone environment variables. Zic will act as if the input contained a link line of the form: <table><tr><td>Link<td>timezone<td>posixrules</table> <dt>-L leapsecondfilename <dd>Read leap second information from the file with the given name. If this option is not used, no leap second information appears in output files. <dt>-v <dd>Complain if a year that appears in a data file is outside the range of years representable by time (2) values. <dt>-s <dd>Limit time values stored in output files to values that are the same whether they're taken to be signed or unsigned. You can use this option to generate SVVS-compatible files. <dt>-y command <dd>Use the given command rather than yearistype when checking year types (see below). </dl> Input lines are made up of fields. Fields are separated from one another by any number of white space characters. Leading and trailing white space on input lines is ignored. An unquoted sharp character (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they're to be used as part of a field. Any line that is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. A rule line has the form: <table border=1> <tr><td>Rule<td>NAME<td>FROM<td>TO<td>TYPE<td>IN<td>ON<td>AT<td>SAVE<td>LETT ER/S <tr><td colspan=10>For example: <tr><td>Rule<td>US<td>1967<td>1973<td>-<td>Apr<td>lastSun<td>2:00<td>1:00<td >D </table> The fields that make up a rule line are: <dl> <dt>NAME <dd>Gives the (arbitrary) name of the set of rules this rule is part of. <dt>FROM <dd>Gives the first year in which the rule applies. Any integer year can be supplied; the Gregorian calendar is assumed. The word minimum (or an abbreviation) means the minimum year representable as an integer. The word maximum (or an abbreviation) means the maximum year representable as an integer. Rules can describe times that are not representable as time values, with the unrepresentable times ignored; this allows rules to be portable among hosts with differing time value types. <dt>TO <dd>Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. <dt>TYPE <dd>Gives the type of year in which the rule applies. If TYPE is - then the rule applies in all years between FROM and TO inclusive. If TYPE is something else, then zic executes the command: yearistype year type To check the type of a year: An exit status of zero is taken to mean that the year is of the given type; An exit status of one is taken to mean that the year is not of the given type. <dt>IN <dd>Names the month in which the rule takes effect. Month names may be abbreviated. <dt>ON <dd>Gives the day on which the rule takes effect. Recognized forms include: <table border=1> <tr><td>5<td>the fifth of the month <tr><td>lastSun<td>the last Sunday in the month <tr><td>lastMon<td>the last Monday in the month <tr><td>Sun>=8<td>first Sunday on or after the eighth <tr><td>Sun<=25<td>last Sunday on or before the 25th </table> Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the ON field. <dt>AT <dd>Gives the time of day at which the rule takes effect. Recognized forms include: <table border=1> <tr><td>2<td>time in hours <tr><td>2:00<td>time in hours and minutes <tr><td>15:00<td>24-hour format time (for times after noon) <tr><td>1:28:14<td>time in hours, minutes, and seconds <tr><td>-<td>equivalent to 0 </table> Where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter w if the given time is local "wall clock" time, s if the given time is local "standard" time, or u (or g or z) if the given time is universal time; in the absence of an indicator, wall clock time is assumed. <dt>SAVE <dd>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 AT field (although, of course, the w and s suffixes are not used). <dt>LETTER/S <dd>Gives the "variable part" (for example, the "S" or "D" in "EST" or "EDT") of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. </dl> A zone line has the form: <table border=1> <tr><td>Zone<td>NAME<td>GMTOFF<td>RULES/SAVE<td>FORMAT<td>[UNTIL] <tr><td colspan=6>For example: <tr><td>Zone<td>Australia/Adelaide<td>9:30<td>Aus<td>CST<td>1971 Oct 31 2:00 </table> The fields that make up a zone line are: <dl> <dt>NAME <dd>The name of the time zone. This is the name used in creating the time conversion information file for the zone. <dt>GMTOFF <dd>The amount of time to add to UTC to get standard time in this zone. This field has the same format as the AT and SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. <dt>RULES/SAVE <dd>The name of the rule(s) that apply in the time zone or, alternately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. <dt>FORMAT <dd>The format for time zone abbreviations in this time zone. The pair of characters %s is used to show where the "variable part" of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. <dt>UNTIL <dd>The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, the time zone information is generated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT columns of a rule; trailing columns can be omitted, and default to the earliest possible value for the missing columns. The next line must be a 'continuation' line; this has the same form as a zone line except that the string "Zone" and the name are omitted, as the continuation line will place information starting at the time specified as the UNTIL field in the previous line in the file used by the previous line. Continuation lines may contain an UNTIL field, just as zone lines do, indicating that the next line is a further continuation. </dl> A link line has the form: <table border=1> <tr><td>Link<td>LINK-FROM<td>LINK-TO <tr><td colspan=3>For example: <tr><td>Link<td>Europe/Istanbul<td>Asia/Istanbul </table> The LINK-FROM field should appear as the NAME field in some zone line; the LINK-TO field is used as an alternate name for that zone. Except for continuation lines, lines may appear in any order in the input. Lines in the file that describes leap seconds have the following form: <table border=1> <tr><td>Leap<td>YEAR<td>MONTH<td>DAY<td>HH:MM:SS<td>CORR<td>R/S <tr><td colspan=7>For example: <tr><td>Leap<td>1974<td>Dec<td>31<td>23:59:60<td>+<td>S </table> The YEAR, MONTH, DAY, and HH:MM:SS fields tell when the leap second happened. The CORR field should be "+" if a second was added or "-" if a second was skipped. <table> <tr><td>  <td> There's no need to document the following, since it's impossible for more than one leap second to be inserted or deleted at a time. The C Standard is in error in suggesting the possibility. See Terry J Quinn, The BIPM and the accurate measure of time, Proc IEEE 79, 7 (July 1991), 894-905. <dl><dt><dd>or "++" if two seconds were added or "--" if two seconds were skipped.</dl></table> The R/S field should be (an abbreviation of) "Stationary" if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) "Rolling" if the leap second time given by the other fields should be interpreted as local wall clock time. <h3>NOTE</h3> For areas with more than two types of local time, you may need to use local standard time in the AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. <h3>FILE</h3> /usr/local/etc/zoneinfo standard directory used for created files <h3>SEE ALSO</h3> newctime(3), tzfile(5), zdump(8) <pre>@(#)zic.8 7.19</pre> This is the HTML version of the file "zic.8" in the tzcode folder. </body> </html>

2 1

FW: Time Zone Issues
by Olson, Arthur David (NCI) April 19, 2000

April 19, 2000

Andre-Tascha is on the time zone mailing list. --ado > -----Original Message----- > From: Andre-Tascha Lamme [SMTP:andre-tascha.lamme@ironriver.com] > Sent: Thursday, April 13, 2000 10:18 PM > To: Olson, Arthur David (NCI) > Subject: Time Zone Issues > > Arthur, > > Figured I would add you to the list of folks I have contacted over the > last couple of days. > > I am putting together some controls for windows developers overseas to > enable them to utilize all aspects of time zones (including the > ever-present > and pain in the rear DST variance). The data you have put together is the > closest thus far to what I am looking for. > > I cannot believe that somebody on the web hasn't posted a > straightforward > database with all the basic info for all applicable regions (well as much > as > can be done with such at least). I have gone through the data2000d.tar.gz > file you posted on the ftp site and has much of the data I am looking for, > but can be a bit confusing. Am I just an idiot? <grin> > > Do you know of this straightforward and exhaustive source (obviously do > not want to do 1000+ clicks to get the data from somebody's java app)... > > many thanks, > > andre'-tascha

4 3

time in Argentina
by Alex LIVINGSTON April 19, 2000

April 19, 2000

Can someone please tell me whether Argentina did, or did not, discontinue observing a fixed, year-round time this year (a time that many would consider "daylight-saving" time), which would have put its clocks back an hour sometime recently (the first change in a decade)? Its powers-that-be seem to have changed their minds several times, but the last I heard, they'd "recinded" the proposal to "introduce daylight-saving time" (quotes only from memory and therefore questionable), which I took to mean they'd decided against re-introducing a non-daylight-saving period, because they seemed to have decided in favour of the status quo, Didn't I read somewhere that someone claimed that the proposed change would actually cause an increase in power consumption, rather than a decrease? This would have to be a classic case of multiple negations combined with mind-boggling ambiguity and perhaps translation difficulties. --Alex _______________ Alex LIVINGSTON IT, Australian Graduate School of Management (AGSM), UNSW SYDNEY NSW 2052 Fax: +61 2 9931-9349 / Phone: +61 2 9931-9264 / Time: UTC + 10 or 11 h. It's the 2000th year, 200th decade, 20th century, and 2nd millennium - the last year of the last decade of the last century of the millennium. (But it's no longer 1999, the 1990s, the 1900s, or the 1000s.) Years since epoch (1-1-1 at 00:00:00) at midday today (Apr. 19): 1999.29772685

2 1

proposed tz patch for Argentine daylight saving last summer
by Paul Eggert April 19, 2000

April 19, 2000

Here's a proposed patch to reflect an error in the current tz data that was reported by Fabian L. Arce Jofre on April 4. Last summer, Argentina observed daylight saving time, but it didn't adjust its clocks because it changed the standard-time UTC offset during the period while it was observing DST. (Isn't politics wonderful?) The current tz data has the correct Argentine wall clock values, but has incorrect values for the the tm_isdst flag and for the time zone name for the period 1999-10-03 to 2000-03-05. =================================================================== RCS file: RCS/southamerica,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- southamerica 2000/03/04 15:31:08 2000.3 +++ southamerica 2000/04/19 05:36:52 2000.3.0.1 @@ -111,24 +111,31 @@ Rule Arg 1989 1992 - Oct Sun>=15 0:00 1: # From Rives McDow (2000-01-10): # On October 3, 1999, 0:00 local, Argentina implemented daylight savings time, # which did not result in the switch of a time zone, as they stayed 9 hours -# from the International Date Line. On March 5, 2000, at 0:00 local time, -# Argentina will come off daylight savings time, which will bring them to 8 -# hours from the International Date Line. +# from the International Date Line. +Rule Arg 1999 only - Oct Sun>=1 0:00 1:00 S +Rule Arg 2000 only - Mar Sun>=1 0:00 0 - # # From Peter Gradelski via Steffen Thorsen (2000-03-01): # We just checked with our San Paulo office and they say the government of # Argentina decided not to become one of the countries that go on or off DST. # So Buenos Aires should be -3 hours from GMT at all times. # +# From Fabian L. Arce Jofre <farcejofre(a)bigfoot.com> (2000-04-04): +# The law that claimed DST for Argentina was derogated by President Fernando +# de la Rua on March 2, 2000, because it would make people spend more energy +# in the winter time, rather than less. The change took effect on March 3. +# # Zone NAME GMTOFF RULES FORMAT [UNTIL] # -# Buenos Aires (BA), Distrito Federal (DF), Santa Cruz (SC), -# Tierra del Fuego (TF) & Antartida e Islas +# Buenos Aires (BA), Capital Federal (CF), Santa Cruz (SC), +# Tierra del Fuego, Antartida e Islas del Atlantico Sur (TF) Zone America/Buenos_Aires -3:53:48 - LMT 1894 Nov -4:16:44 - CMT 1920 May # Cordoba Mean Time -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 - -3:00 Arg AR%sT + -3:00 Arg AR%sT 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 + -3:00 - ART # # Santa Fe (SF), Entre Rios (ER), Corrientes (CN), Misiones (MN), Chaco (CC), # Formosa (FM), La Pampa (LP), Chubut (CH) @@ -137,6 +144,8 @@ Zone America/Rosario -4:02:40 - LMT 1894 -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 -3:00 Arg AR%sT 1991 Jul + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 -3:00 - ART # # Cordoba (CB), Santiago del Estero (SE), Salta (SA), Tucuman (TM), La Rioja (LR), San Juan (SJ), San Luis (SL), @@ -146,6 +155,8 @@ Zone America/Cordoba -4:16:44 - LMT 1894 -4:00 - ART 1930 Dec -4:00 Arg AR%sT 1969 Oct 5 -3:00 Arg AR%sT 1990 Jul + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 -3:00 - ART # # Jujuy (JY) @@ -157,6 +168,8 @@ Zone America/Jujuy -4:21:12 - LMT 1894 N -4:00 - WART 1991 Oct 6 -4:00 1:00 WARST 1992 Mar 15 -4:00 - WART 1992 Oct 18 + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 -3:00 - ART # # Catamarca (CT) @@ -167,6 +180,8 @@ Zone America/Catamarca -4:23:08 - LMT 18 -3:00 Arg AR%sT 1990 Jul -3:00 - ART 1991 Jul -3:00 Arg AR%sT 1992 Jul + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 -3:00 - ART # # Mendoza (MZ) @@ -178,6 +193,8 @@ Zone America/Mendoza -4:35:16 - LMT 1894 -4:00 - WART 1991 Oct 15 -4:00 1:00 WARST 1992 Mar 1 -4:00 - WART 1992 Oct 18 + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 -3:00 - ART # Aruba

1 0

support for C99 strftime %F and %z formats, plus Solaris 8 fix
by Paul Eggert April 13, 2000

April 13, 2000

The new C Standard specifies two new formats for strftime: %F and %z. Here's a proposed patch to add support for this. I ran into a Solaris 8 porting problem when debugging this, and enclose a patch for this as well. =================================================================== RCS file: RCS/Makefile,v retrieving revision 2000.1 retrieving revision 2000.1.0.1 diff -pu -r2000.1 -r2000.1.0.1 --- Makefile 2000/01/18 14:21:10 2000.1 +++ Makefile 2000/04/13 19:11:13 2000.1.0.1 @@ -88,6 +88,8 @@ LDLIBS= # Add the following to the end of the "CFLAGS=" line as needed. # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS +# -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares +# ctime_r and asctime_r incompatibly with the POSIX standard. # -DHAVE_LONG_DOUBLE=1 if your compiler supports the `long double' type # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) =================================================================== RCS file: RCS/private.h,v retrieving revision 1999.5 retrieving revision 1999.5.0.1 diff -pu -r1999.5 -r1999.5.0.1 --- private.h 1999/08/17 18:09:09 1999.5 +++ private.h 2000/04/13 19:11:13 1999.5.0.1 @@ -38,6 +38,10 @@ static char privatehid[] = "@(#)private. #define HAVE_GETTEXT 0 #endif /* !defined HAVE_GETTEXT */ +#ifndef HAVE_INCOMPATIBLE_CTIME_R +#define HAVE_INCOMPATIBLE_CTIME_R 1 +#endif /* !defined INCOMPATIBLE_CTIME_R */ + #ifndef HAVE_SETTIMEOFDAY #define HAVE_SETTIMEOFDAY 3 #endif /* !defined HAVE_SETTIMEOFDAY */ @@ -66,6 +70,11 @@ static char privatehid[] = "@(#)private. #define LOCALE_HOME "/usr/lib/locale" #endif /* !defined LOCALE_HOME */ +#if HAVE_INCOMPATIBLE_CTIME_R +#define asctime_r _incompatible_asctime_r +#define ctime_r _incompatible_ctime_r +#endif /* HAVE_INCOMPATIBLE_CTIME_R */ + /* ** Nested includes */ @@ -203,6 +212,28 @@ void icfree P((char * pointer)); void ifree P((char * pointer)); char * scheck P((const char *string, const char *format)); +/* +** External declarations, possibly renamed to private identifiers. +*/ +#ifndef USG_COMPAT +#define timezone _timezone +#define daylight _daylight +#endif +#ifndef ALTZONE +#define altzone _altzone +#endif +/* strftime needs these variables if TM_GMTOFF is not defined. */ +#ifndef TM_GMTOFF +#define USG_COMPAT +#define ALTZONE +#endif +#ifdef USG_COMPAT +extern time_t timezone; +extern int daylight; +#endif +#ifdef ALTZONE +extern time_t altzone; +#endif /* ** Finally, some convenience items. @@ -277,6 +308,13 @@ char * scheck P((const char *string, con #define TZ_DOMAIN "tz" #endif /* !defined TZ_DOMAIN */ +#if HAVE_INCOMPATIBLE_CTIME_R +#undef asctime_r +#undef ctime_r +char *asctime_r P((struct tm const *, char *)); +char *ctime_r P((time_t const *, char *)); +#endif /* HAVE_INCOMPATIBLE_CTIME_R */ + /* ** UNIX was a registered trademark of UNIX System Laboratories in 1993. */ =================================================================== RCS file: RCS/strftime.c,v retrieving revision 1999.9 retrieving revision 1999.9.0.1 diff -pu -r1999.9 -r1999.9.0.1 --- strftime.c 1999/11/08 19:54:36 1999.9 +++ strftime.c 2000/04/13 19:11:13 1999.9.0.1 @@ -247,6 +247,9 @@ label: case 'e': pt = _conv(t->tm_mday, "%2d", pt, ptlim); continue; + case 'F': + pt = _fmt("%Y-%m-%d", t, pt, ptlim, warnp); + continue; case 'H': pt = _conv(t->tm_hour, "%02d", pt, ptlim); continue; @@ -489,10 +492,46 @@ label: pt = _add(t->TM_ZONE, pt, ptlim); else #endif /* defined TM_ZONE */ - if (t->tm_isdst == 0 || t->tm_isdst == 1) { - pt = _add(tzname[t->tm_isdst], + if (0 <= t->tm_isdst) + pt = _add(tzname[t->tm_isdst != 0], pt, ptlim); - } else pt = _add("?", pt, ptlim); + continue; + case 'z': + { + int diff; + char const *sign; + if (t->tm_isdst < 0) + continue; +#ifdef TM_GMTOFF + diff = t->TM_GMTOFF; +#else /* !defined TM_GMTOFF */ + /* + ** C99 says that the UTC offset must + ** be computed by looking only at + ** tm_isdst. This requirement is + ** incorrect, since it means the code + ** must rely on magic (in this case + ** altzone and timezone), and the + ** magic might not have the correct + ** offset. Doing things correctly is + ** tricky and requires disobeying C99; + ** see GNU C strftime for details. + ** For now, punt and conform to the + ** standard, even though it's incorrect. + ** + */ + diff = - (t->tm_isdst ? altzone : timezone); +#endif /* !defined TM_GMTOFF */ + if (diff < 0) { + sign = "-"; + diff = -diff; + } else + sign = "+"; + pt = _add(sign, pt, ptlim); + diff /= 60; + pt = _conv((diff/60)*100 + diff%60, + "%04d", pt, ptlim); + } continue; case '+': pt = _fmt(Locale->date_fmt, t, pt, ptlim,

1 0

FW: [Fwd: Day light savings time]
by Olson, Arthur David (NCI) April 12, 2000

April 12, 2000

Neither higgoman(a)eisa.net.au nor webmaster(a)holidayfestival.com are on the time zone mailing list; direct any replies appropriately. --ado > -----Original Message----- > From: Brian Prescott-Decie [SMTP:bdecie@holidayfestival.com] > Sent: Tuesday, April 11, 2000 1:32 AM > To: tz(a)elsie.nci.nih.gov > Subject: [Fwd: Day light savings time] > > > > -------- Original Message -------- > Subject: Day light savings time > Date: Tue, 11 Apr 2000 15:23:23 +1000 > From: "Eisa" <higgoman(a)eisa.net.au> > To: <webmaster(a)HolidayFestival.com> > > This year day light savings will start earlier in Sydney because of the > olympics not sure of the exact date will let you know.

2 1

Request for Addition to the Mailing List
by Wong, Ren April 12, 2000

April 12, 2000

Would you please add me to your mailing list? Thanks. My company is currently installing Mobile Pre-Paid Service in Asia, Africa, Indian Ocean, and Europe on Pentium based UnixWare 2.1.3 UnixWare 7.1.0 systems. Your information has been invaluable to us. My responsibility is to ensure the correct setup of the timezone on our systems. Without the information you provided, we would not be able to calculate call duration for the pre-paid mobile subscribers. Ren Wong Software Development IN Division Comverse Network Systems 1025 Briggs Rd., Suite 100 Mt. Laurel, NJ 08054 Voice (856) 608-2859 Fax (856) 866-8850

1 0

[Fwd: Day light savings time]
by Brian Prescott-Decie April 11, 2000

April 11, 2000

-------- Original Message -------- Subject: Day light savings time Date: Tue, 11 Apr 2000 15:23:23 +1000 From: "Eisa" <higgoman(a)eisa.net.au> To: <webmaster(a)HolidayFestival.com> This year day light savings will start earlier in Sydney because of the olympics not sure of the exact date will let you know.

1 0

FW: DST law derogation in Argentina
by Olson, Arthur David (NCI) April 4, 2000

April 4, 2000

Fabián is not on the time zone mailing list; be sure to direct any replies appropriately. --ado -----Original Message----- From: Fabián L. Arce Jofré [SMTP:fabian@limite.yi.org] Sent: Monday, April 03, 2000 11:54 PM To: tz(a)elsie.nci.nih.gov Subject: DST law derogation in Argentina Hello, my name is Fabián L. Arce Jofré, and I'm from Argentina, and this e-mail message is for tell you about the time zone change in Argentina recently -- the law that established DST was derogated recently due to an evaluation of the government about more waste of energy than before. I cut the Argentina part in the southamerica file and send it separately, I think it's the best way. I corrected the time zone data and the name of a district, Distrito Federal (DF) for Capital Federal (CF), the correct name in Argentina. If you have questions or comments, don't hesitate to mail me at farcejofre(a)bigfoot.com. Sincerely, Fabián L. Arce Jofré Buenos Aires, Argentina farcejofre(a)bigfoot.com <<argentina-20000404>>

1 0

DST law derogation in Argentina
by Fabián L. Arce Jofré April 4, 2000

April 4, 2000

Hello, my name is Fabián L. Arce Jofré, and I'm from Argentina, and this e-mail message is for tell you about the time zone change in Argentina recently -- the law that established DST was derogated recently due to an evaluation of the government about more waste of energy than before. I cut the Argentina part in the southamerica file and send it separately, I think it's the best way. I corrected the time zone data and the name of a district, Distrito Federal (DF) for Capital Federal (CF), the correct name in Argentina. If you have questions or comments, don't hesitate to mail me at farcejofre(a)bigfoot.com. Sincerely, Fabián L. Arce Jofré Buenos Aires, Argentina farcejofre(a)bigfoot.com

1 0

LA Times: Daylight Saving Ticks Off Millions in Mexico
by Paul Eggert April 2, 2000

April 2, 2000

On page A4 of today's Los Angeles Times, staff writer Mary Beth Sheridan writes: COLIMA, Mexico--Soledad Castillo has a list of grave problems she wants Mexico's next president to solve. Low salaries. Rising crime. Poverty. But a different issue was troubling the 41-year-old cleaning woman one recent morning as she attended a campaign rally in this city in southwestern Mexico. It was something more urgent, more sinister--an evil that has aroused Mexicans nationwide in an extraordinary political backlash. Daylight saving time. Sheridan goes on to write that the issue has managed to push issues like the presidential race, poverty, and crime off the front pages. Half a dozen Mexican states have organized plebiscites on whether to implement DST, and the ruling party presidential candidate has promised to limit DST to 4 months instead of 6. Here's the URL of the complete story: http://www.latimes.com/news/nation/20000402/t000030885.html

1 0

daylights savings time
by SEETA57＠aol.com April 1, 2000

April 1, 2000

when do we set our clocks forward 1 hour

1 0

Rational behind lcl_is_set?
by John Hawkinson March 29, 2000

March 29, 2000

[ If you could cc me on replies until my subscription request is processed, I'd appreciate it. ] I recently made the oberservation that tzset() seems to keep state on whether it has read the system localtime file and if so, subsequent invokations of tzset() do not re-read the file. This seems to prevent applications which call tzset() from obtaining new time zone information should the system change. For instance, my laptop recently travelled through: US/Eastern -> US/Central -> US/Pacific -> Pacific/Gambier -> Pacific/Honolulu -> Pacific/Midway -> Pacific/Fiji -> Pacific/Auckland -> Pacific/Kosrae -> Australia/Sydney -> Australia/Adelaide during which time my /etc/localtime file changed as appropriate. It would have been nice if, had my MUA called tzset() across each time zone, times would have been correct. But tzset() seems to cache old data. In my case, $TZ is unset so tzsetwall() is called, and it's first act is: if (lcl_is_set < 0) return; lcl_is_set = -1; So there seems to be no hope of causing tzset() to re-read this data. Ironically enough, it seems that if the value of TZ changes, tzset() will change state. This seems odd as it seems far more likely that the system's /etc/localtime file will change, than a process will actually change its own TZ environment variable in mid-flight. I presume that this caching was added as an optimization since strftime() calls tzset() during each invokations. Is there no way around it, short of changing the API and adding some function to reload timezone data, or giving up the caching and having tzset() reread localtime each time? The presence of STD_INSPIRED implies that new functions could be added, but I presume there's a relatively high hurdle to doing so. Incidently, tzset() seems a bit underdocumented. Specifically newtzset(3) fails to indicate whether programs should call tzset() by hand, or whether they should never bother, etc., etc. If I knew the answer I would offer a patch. Thanks. --jhawk p.s.: You're free to tell me that I'm foolish for wanting my time to change accurately on transoceanic flighs, but it is terribly nice to have one's mail timestamped appropriate, at the very least.

1 0

Lithuanian time zone update
by Marius Gedminas March 26, 2000

March 26, 2000

Lithuania gave up shifting to summer time as planned. Here is a patch for europe file from tzdata2000d.tar.gz. Note that I'm not sure about the exact time of this change, I just copied 1:00u from the line above. Marius Gedminas -- "Linux: the operating system with a CLUE... Command Line User Environment". (seen in a posting in comp.software.testing)

1 0

Your site has been included on OpenHere
by Sara＠openhere.com March 23, 2000

March 23, 2000

Hi, Your site was recently submitted to OpenHere.com. We have reviewed your site and decided to include it as follows: Link: http://www.twinsun.com/tz/tz-link.htm Title: Sources for Time Zone and Daylight Saving Time Data Description: OpenHere Category: http://www.openhere.com/edu/Ref/Time/ As you are listed as a contact person on the home page of this site, I am dropping you a quick note to let you know about your inclusion on OpenHere. OpenHere is one of the 10 largest index and search sites on the Internet and is specifically focused on creating resources for the family. You can dynamically modify your site's listing at any time, or include your site's listing in other categories on OpenHere.com. When you modify your site's listing, it is automatically placed at the top of the category in which it is included, and is placed first in the search engine results for the keywords relating to your site. To modify, add or delete your listing: 1. Go to the OpenHere category where your site is listed. 2. Click on the "Suggest a Site" link. 3. Follow the instructions for changing your listing. All of the modifications you submit to OpenHere.com are processed in real time. As soon as you see the response to your submission, your site listing should be updated. OpenHere is frequented by both children and families. As a result, www.OpenHere.com does not include links to material which is illegal to display to minors. If you have a question, or need help in any way, please just send me a note. Yes, I am a real person! Sara www.OpenHere.com Your key to the Net!

1 0

FW: Estonia will not switch to summer time anymore starting from 2000
by Olson, Arthur David (NCI) March 20, 2000

March 20, 2000

Taavi Talvik is not on the time zone mailing list; direct any replies appropriately. --ado -----Original Message----- From: Taavi Talvik [SMTP:taavi@uninet.ee] Sent: Friday, March 17, 2000 7:00 AM To: tz(a)elsie.nci.nih.gov Subject: Estonia will not switch to summer time anymore starting from 2000 Following patch against zone files in FreeBSD: --- /usr/src/share/zoneinfo/europe.old Sun Feb 14 19:13:56 1999 +++ /usr/src/share/zoneinfo/europe Fri Mar 17 13:44:38 2000 @@ -1265,6 +1265,8 @@ # for their standard and summer times. He says no, they use "suveaeg" # (summer time) and "talveaeg" (winter time). +# Starting from 2000 Estonia will not switch to summer time anymore. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tallinn 1:39:00 - LMT 1880 1:39:00 - TMT 1918 Feb # Tallinn Mean Time @@ -1276,7 +1278,8 @@ 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 1:00 EEST 1989 Sep 24 2:00s 2:00 C-Eur EE%sT 1998 Sep 22 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 + 2:00 - EET # Finland # See Sweden for when the Gregorian calendar was adopted. ----------------------------------------------------------- Taavi Talvik | Internet: taavi(a)uninet.ee Unineti Andmeside AS | phone: +372 6405150 Ravala pst. 10 | fax: +372 6405151 Tallinn 10143, Estonia |

1 0

Estonia will not switch to summer time anymore starting from 2000
by Taavi Talvik March 17, 2000

March 17, 2000

Following patch against zone files in FreeBSD: --- /usr/src/share/zoneinfo/europe.old Sun Feb 14 19:13:56 1999 +++ /usr/src/share/zoneinfo/europe Fri Mar 17 13:44:38 2000 @@ -1265,6 +1265,8 @@ # for their standard and summer times. He says no, they use "suveaeg" # (summer time) and "talveaeg" (winter time). +# Starting from 2000 Estonia will not switch to summer time anymore. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Tallinn 1:39:00 - LMT 1880 1:39:00 - TMT 1918 Feb # Tallinn Mean Time @@ -1276,7 +1278,8 @@ 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 1:00 EEST 1989 Sep 24 2:00s 2:00 C-Eur EE%sT 1998 Sep 22 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 + 2:00 - EET # Finland # See Sweden for when the Gregorian calendar was adopted. ----------------------------------------------------------- Taavi Talvik | Internet: taavi(a)uninet.ee Unineti Andmeside AS | phone: +372 6405150 Ravala pst. 10 | fax: +372 6405151 Tallinn 10143, Estonia |

1 0

tzdata2000d.tar.gz
by Olson, Arthur David (NCI) March 14, 2000

March 14, 2000

The file ftp://elsie.nci.nih.gov/pub/tzdata2000d.tar.gz is now available; this incorporates the Latvia-related changes circulated last week on the time zone mailing list by Paul Eggert. There is no change to tzcode2000c.tar.gz --ado

1 0

FW: no DST time in Latvia
by Olson, Arthur David (NCI) March 6, 2000

March 6, 2000

Note that Andrei is not on the time zone mailing list; be sure to direct any replies appropriately. --ado -----Original Message----- From: Andrei Ivanov [SMTP:Andrei.Ivanov@Realogic.lv] Sent: Monday, March 06, 2000 6:28 AM To: tz(a)elsie.nci.nih.gov Subject: FYI: no DST time in Latvia Hi This year Latvia will not switch to Daylight Savings Time (as specified in The Regulations of the Cabinet of Ministers of the Rep. of Latvia of 29-Feb-2000 (#79)), so a minor patch [attached] may be applied to the 'europe' file (as part of tzdata2000c.tar.gz package). Regards, -- andrei <<Diff for europe>>

3 2

FYI: no DST time in Latvia
by Andrei Ivanov March 6, 2000

March 6, 2000

Hi This year Latvia will not switch to Daylight Savings Time (as specified in The Regulations of the Cabinet of Ministers of the Rep. of Latvia of 29-Feb-2000 (#79)), so a minor patch [attached] may be applied to the 'europe' file (as part of tzdata2000c.tar.gz package). Regards, -- andrei

1 0

Another ISO 3166 list
by Oscar van Vlijmen March 5, 2000

March 5, 2000

Just found another list with ISO 3166 designations: "INTERNET ISO 3166-BASED TOP LEVEL DOMAIN SURVEY Last update: October 15, 1999 | Copyright ITU 1999" This short page refers to the complete list of approx. 424 KB. On this list you find the ISO3166 2- & 3-letter designations including all addresses of administrative bodies/people of all designated top-level country/territory domains, including Isle of Man, Guernsey, etcetera. http://www.itu.int/net/cctlds/ Regards, Oscar van Vlijmen 2000-03-05

1 0