- tz - lists.iana.org

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