From: Art...@cswamp.apana.org.au (Arthur Marsh)
Path: gmd.de!nntp.gmd.de!xlink.net!howland.reston.ans.net!agate!
ihnp4.ucsd.edu!munnari.oz.au!news.uwa.edu.au!nodecg.ncc.telecomwa.oz.au!
netbsd08.dn.itg.telecom.com.au!orca1.vic.design.telecom.com.au!
picasso.cssc-syd.tansu.com.au!wabbit.cc.uow.edu.au!metro!news.cs.su.oz.au!
news.adelaide.edu.au!gateway.dircsa.org.au!cleese.apana.org.au!hal9000!
cswamp!Fredgate
Newsgroups: comp.unix.unixware
Subject: Daylight saving time in UW1.1
Message-ID: <767043120.AA04204@cswamp.apana.org.au>
Date: Fri, 22 Apr 1994 03:22:19
X-FTN-To: g...@summit.novell.com
Lines: 22
On Tue 12 Apr at 16:31 g...@summit.novell.com wrote:
g> From: g...@summit.novell.com (George F Demarest)
g> Message-ID: <2oeesg$...@bird.summit.novell.com>
g> [from USG development]
g> I don't know whether my UW1.1 machine's behavior is any
g> help, but it didn't advance with the changeover, either.
g> I quickly found that my TZ environment variable was set
g> to "EST5". This value does not even admit that there is
g> an alternate time! I found that /etc/TIMEZONE sets the
g> string. I suspect that somehow this file was munged
g> when they tried to move back from the ":US/Eastern"-style
g> values, but I didn't pursue the issue The right value
g> for NJ is "EST5EDT", for Central time, try "CST6CDT".
OK, how do we set the timezone correctly for Adelaide, which is nine and one
half hours ahead of UTC?
Arthur.
* Origin: Camelot Swamp MJCNA, Hawthorndene, Sth Australia (8:7000/8)
Newsgroups: comp.unix.unixware
Path: bga.com!news.sprintlink.net!hookup!swrinde!cs.utexas.edu!
howland.reston.ans.net!pipex!Q.icl.co.uk!dsbc!jjf
From: j...@dsbc.icl.co.uk (J J Farrell)
Subject: Re: Daylight saving time in UW1.1
Message-ID: <Cp6IvD.Evy@dsbc.icl.co.uk>
Organization: International Computers Limited
References: <767043120.AA04204@cswamp.apana.org.au>
Date: Mon, 2 May 1994 14:28:24 GMT
Lines: 13
In article <767043120.AA04...@cswamp.apana.org.au> Art...@cswamp.apana.org.au
(Arthur Marsh) writes:
>
>OK, how do we set the timezone correctly for Adelaide, which is nine and one
>half hours ahead of UTC?
Not sure about Adelaide, but the following should do for the Cook Islands:
KDT9:30KST10:00,63/5:00,302/20:00
Try the environ(5) and ctime(3) man pages (obvious, eh?).
My opinions; I do not speak for my employer.
Newsgroups: comp.unix.unixware
Path: bga.com!news.sprintlink.net!hookup!usc!howland.reston.ans.net!EU.net!
uknet!uel!msohnius
From: msohn...@novell.co.uk (Martin Sohnius)
Subject: Re: Daylight saving time in UW1.1
Sender: n...@novell.co.uk
Message-ID: <Cp9x6n.7uB@novell.co.uk>
Date: Wed, 4 May 1994 10:30:22 GMT
References: <767043120.AA04204@cswamp.apana.org.au>
Organization: Novell UNIX System Labs Europe Ltd.
X-Newsreader: TIN [version 1.2 PL0]
Lines: 67
Arthur Marsh (Art...@cswamp.apana.org.au) wrote:
: OK, how do we set the timezone correctly for Adelaide, which is nine and one
: half hours ahead of UTC?
Let me do a wide sweep on this.
UnixWare supports two different styles of timezone handling.
One is what I may call "System V" style, with the TZ environment variable
as described in environ(5). This is the TZ that does not start with a
':'. Jim Henderson tells me that it is very difficult to make that work
correctly anywhere in the Southern Hemisphere where they have Summer
Time. His advice (which he also gives when teaching SCO Unix) is "change
your timezone settings manually twice a year". For Adelaide that would be
TZ=CST-9:30 for winter (in Oz)
TZ=CST-10:30 for summer
Note also that the October rule for many parts of Australia ("next-to-last
Sunday in October") cannot be implemented with the "System V" style TZ.
(NB nor can the British rule, "day after 4th Saturday in October").
So, we preferably use the "Berkeley style TZ", i.e. the one which starts
with a ':'. For Adelaide, that is:
TZ=:Australia/South
Timezone information of this form (defined by Posix, I think, as
"implementation dependent") is read from a binary file (in this case
/usr/lib/locale/TZ/Australia/South) when needed by the time-conversion
library functions. The utility which generates these binary files is
called zic(1M), and its manual page also describes the format of the
ASCII source files used by zic.
The source files for zic are part of the softint package in the SDK -
so you haven't got'em on a vanilla UW machine without the SDK. However,
if you are unhappy with your current settings (or live in a part of the world
not catered for), you can create your own. The one which includes in-
formation for Southern Australia is called /usr/lib/locale/TZ/australasia,
and makes for some amusing reading! (Unfortunately, it's got a Sun
Microsystems Inc. copyright on it, so I can't post it here.)
The rules currently applying to Australia/South read like this:
Rule Oz 1986 max - Oct Sun<=24 2:00 1:00 -
Rule Oz 1987 max - Mar Sun<=21 3:00 0 -
Zone Australia/South 9:30 Oz CST
This means: "Normal time is UCT+9:30. Set clocks one hour forward at 2am
normal time on the last Sunday on or before the 24th of Oct (i.e. "next-to-last
Sunday in Oct") and set them back to normal at 3am summer time on the third
Sunday in March. The time zone is called CST, both summer and winter."
(Upon indeed reading the commentary in the australasia file, I must say that
I am less than certain that Adelaide, or anyone else downunder, actually
follows these rules!)
--
Martin Sohnius
Novell Labs Europe
Bracknell, England
+44-344-724031
(My opinions may not be those of Novell!)
Newsgroups: comp.unix.unixware
Path: bga.com!news.sprintlink.net!hookup!swrinde!elroy.jpl.nasa.gov!
ucla-cs!twinsun!eggert
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Daylight saving time in UW1.1
Message-ID: <CpAwFA.Lz6@twinsun.com>
Sender: use...@twinsun.com
Nntp-Posting-Host: tattoo
Organization: Twin Sun Inc, El Segundo, CA, USA
References: <767043120.AA04204@cswamp.apana.org.au> <Cp9x6n.7uB@novell.co.uk>
<Cp6IvD.Evy@dsbc.icl.co.uk>
Date: Wed, 4 May 1994 23:11:32 GMT
Lines: 71
Arthur Marsh (Art...@cswamp.apana.org.au) writes:
> OK, how do we set the timezone correctly for Adelaide, which is nine and one
> half hours ahead of UTC?
j...@dsbc.icl.co.uk (J J Farrell) replies:
> Not sure about Adelaide, but the following should do for the Cook Islands:
> KDT9:30KST10:00,63/5:00,302/20:00
Even if that works this year, it won't work next year. Your best bet
is to install Arthur David Olson's most recent time zone tables, which
you can FTP from elsie.nci.nih.gov in pub/tz*. (The UW 1.1 tables are
ancient and less complete.) E.g. for the Cook Islands you'd set
TZ=':Pacific/Rarotonga' which would use the following rule taken from
the `australasia' source file:
# Cook Is
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Cook 1978 only - Nov 12 0:00 0:30 HD
Rule Cook 1979 max - Mar Sun>=1 0:00 0 H
Rule Cook 1979 max - Oct lastSun 0:00 0:30 HD
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Pacific/Rarotonga -10:39:04 - LMT 1901 # Avarua
-10:30 - CIST 1978 Nov 12 # Cook Is ST
-10:00 Cook T%sT
msohn...@novell.co.uk (Martin Sohnius) also replies that the tz table
> which includes information for Southern Australia is called
> /usr/lib/locale/TZ/australasia, and makes for some amusing reading!
> (Unfortunately, it's got a Sun Microsystems Inc. copyright on it,
> so I can't post it here.)
That's odd: /usr/share/lib/zoneinfo/australasia _doesn't_ have a Sun
copyright notice in Solaris 2.3. The Sun copyright notices in some of
the related files (e.g. northamerica) are a bit bogus, since that data
was derived from an ancient version of Olson's tables, and Sun's
changes are minimal. Better to go to the source. Here is Olson's
latest table for Adelaide, which you'd use by setting
TZ=':Australia/Adelaide'. Australian time zone rules tend to change a
lot, so if you have any corrections please mail them to
t...@elsie.nci.nih.gov for general use in the future.
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Aus 1895 only - Jan 1 0:00 0 -
# Shanks gives 1917 Jan 1 0:01; go with Whitman (and guess 2:00).
Rule Aus 1916 only - Oct 1 2:00 1:00 -
Rule Aus 1917 only - Mar 25 2:00 0 -
Rule Aus 1942 only - Jan 1 2:00 1:00 -
Rule Aus 1942 only - Mar 29 2:00 0 -
Rule Aus 1942 only - Sep 27 2:00 1:00 -
Rule Aus 1943 1944 - Mar lastSun 2:00 0 -
Rule Aus 1943 only - Oct 3 2:00 1:00 -
# Whitman says W Australia didn't use DST in 1943/1944, and that
# 1944/1945 was just like 1943/1944; go with Shanks.
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule AS 1971 1985 - Oct lastSun 2:00 1:00 -
Rule AS 1986 only - Oct 19 2:00 1:00 -
Rule AS 1987 max - Oct lastSun 2:00 1:00 -
Rule AS 1972 only - Feb 27 3:00 0 -
Rule AS 1973 1985 - Mar Sun>=1 3:00 0 -
Rule AS 1986 1989 - Mar Sun>=15 3:00 0 -
Rule AS 1990 max even Mar Sun>=22 3:00 0 -
Rule AS 1990 max odd Mar Sun>=1 3:00 0 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb
9:00 - CST 1899 May
9:30 - CST 1917 Jan 1 0:01
9:30 Aus CST 1971 Oct lastSun 2:00
9:30 AS CST
Newsgroups: comp.unix.unixware
Path: gmd.de!nntp.gmd.de!xlink.net!howland.reston.ans.net!EU.net!uknet!uel!
msohnius
From: msohn...@novell.co.uk (Martin Sohnius)
Subject: Re: Daylight saving time in UW1.1
Sender: n...@novell.co.uk
Message-ID: <CpC896.53r@novell.co.uk>
Date: Thu, 5 May 1994 16:24:42 GMT
References: <767043120.AA04204@cswamp.apana.org.au> <Cp9x6n.7uB@novell.co.uk>
<Cp6IvD.Evy@dsbc.icl.co.uk> <CpAwFA.Lz6@twinsun.com>
Organization: Novell UNIX System Labs Europe Ltd.
X-Newsreader: TIN [version 1.2 PL0]
Lines: 110
Paul Eggert (egg...@twinsun.com) wrote:
: Arthur Marsh (Art...@cswamp.apana.org.au) writes:
: > OK, how do we set the timezone correctly for Adelaide, which is nine and one
: > half hours ahead of UTC?
: j...@dsbc.icl.co.uk (J J Farrell) replies:
: > Not sure about Adelaide, but the following should do for the Cook Islands:
: > KDT9:30KST10:00,63/5:00,302/20:00
: Even if that works this year, it won't work next year. Your best bet
: is to install Arthur David Olson's most recent time zone tables, which
: you can FTP from elsie.nci.nih.gov in pub/tz*. (The UW 1.1 tables are
: ancient and less complete.) E.g. for the Cook Islands you'd set
: TZ=':Pacific/Rarotonga' which would use the following rule taken from
: the `australasia' source file:
: # Cook Is
: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
: Rule Cook 1978 only - Nov 12 0:00 0:30 HD
: Rule Cook 1979 max - Mar Sun>=1 0:00 0 H
: Rule Cook 1979 max - Oct lastSun 0:00 0:30 HD
: # Zone NAME GMTOFF RULES FORMAT [UNTIL]
: Zone Pacific/Rarotonga -10:39:04 - LMT 1901 # Avarua
: -10:30 - CIST 1978 Nov 12 # Cook Is ST
: -10:00 Cook T%sT
: msohn...@novell.co.uk (Martin Sohnius) also replies that the tz table
: > which includes information for Southern Australia is called
: > /usr/lib/locale/TZ/australasia, and makes for some amusing reading!
: > (Unfortunately, it's got a Sun Microsystems Inc. copyright on it,
: > so I can't post it here.)
: That's odd: /usr/share/lib/zoneinfo/australasia _doesn't_ have a Sun
: copyright notice in Solaris 2.3. The Sun copyright notices in some of
: the related files (e.g. northamerica) are a bit bogus, since that data
: was derived from an ancient version of Olson's tables, and Sun's
: changes are minimal. Better to go to the source. Here is Olson's
: latest table for Adelaide, which you'd use by setting
: TZ=':Australia/Adelaide'. Australian time zone rules tend to change a
: lot, so if you have any corrections please mail them to
: t...@elsie.nci.nih.gov for general use in the future.
: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
: Rule Aus 1895 only - Jan 1 0:00 0 -
: # Shanks gives 1917 Jan 1 0:01; go with Whitman (and guess 2:00).
: Rule Aus 1916 only - Oct 1 2:00 1:00 -
: Rule Aus 1917 only - Mar 25 2:00 0 -
: Rule Aus 1942 only - Jan 1 2:00 1:00 -
: Rule Aus 1942 only - Mar 29 2:00 0 -
: Rule Aus 1942 only - Sep 27 2:00 1:00 -
: Rule Aus 1943 1944 - Mar lastSun 2:00 0 -
: Rule Aus 1943 only - Oct 3 2:00 1:00 -
: # Whitman says W Australia didn't use DST in 1943/1944, and that
: # 1944/1945 was just like 1943/1944; go with Shanks.
: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
: Rule AS 1971 1985 - Oct lastSun 2:00 1:00 -
: Rule AS 1986 only - Oct 19 2:00 1:00 -
: Rule AS 1987 max - Oct lastSun 2:00 1:00 -
: Rule AS 1972 only - Feb 27 3:00 0 -
: Rule AS 1973 1985 - Mar Sun>=1 3:00 0 -
: Rule AS 1986 1989 - Mar Sun>=15 3:00 0 -
: Rule AS 1990 max even Mar Sun>=22 3:00 0 -
: Rule AS 1990 max odd Mar Sun>=1 3:00 0 -
: # Zone NAME GMTOFF RULES FORMAT [UNTIL]
: Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb
: 9:00 - CST 1899 May
: 9:30 - CST 1917 Jan 1 0:01
: 9:30 Aus CST 1971 Oct lastSun 2:00
: 9:30 AS CST
I sure hit a hornet's nest here. Actually, Andrew Josey dug out for me
the exchanges that had gone on in the SVR4 newsgroup in November 1990 on
the general subject of Olson's method (yes, I now know the name).
Apparently, very few things stir the imagination, and the keyboard urge, as
much as fiddling around with time. What seems to happen with respect to
zic source, is that someone, at some point, downloads the most up-to-date
version, puts it into the code (with or without some copyright -- and
believe me, the ones on UW1.1 do have Sun copyrights), ships it and
forgets it. Hence even 1.1.1 still ships with "Oct lastSun" for UK-Eire.
(I filed the bug long ago, complete with the info sheet from Her Majesty's
Nautical Almanac Office at the Royal Greenwich Observatory.)
More seriously: it's very nice to be able to look up whether summer time
was in force in 1066, but please, please comment out all that stuff before
running zic. Unix clocks start at 00:00 GMT (as it was then called) on
1970 Jan 1. No time conversion on the system will need anything before that,
and for that matter, why do you need to know whether summer time was in
force even last year? Where does it matter?
Put in the current rules and keep the compiled files small. they need to be
read in and digested by the various library functions. Don't bloat them.
PS. Anyone contemplated the fact that before 1928 or thereabouts, Astronomical
Time changed the date at noon? Feel like implementing TZ=:Astronomy?
PPS. What ever happened to leap seconds? A UnixWare machine booted in
Jan.1970 would be 12 seconds fast today! Major software project lurking.
--
Martin Sohnius
Novell Labs Europe
Bracknell, England
+44-344-724031
(My opinions may not be those of Novell!)
Newsgroups: comp.unix.unixware
Path: bga.com!news.sprintlink.net!rtp.vnet.net!news1.digex.net!
news.intercon.com!panix!MathWorks.Com!europa.eng.gtefsd.com!
howland.reston.ans.net!usc!elroy.jpl.nasa.gov!ucla-cs!twinsun!eggert
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: Daylight saving time in UW1.1
Message-ID: <CpGx5v.ADL@twinsun.com>
Sender: use...@twinsun.com
Nntp-Posting-Host: twinsun
Organization: Twin Sun Inc, El Segundo, CA, USA
References: <767043120.AA04204@cswamp.apana.org.au> <Cp9x6n.7uB@novell.co.uk>
<Cp6IvD.Evy@dsbc.icl.co.uk> <CpAwFA.Lz6@twinsun.com> <CpC896.53r@novell.co.uk>
Date: Sun, 8 May 1994 05:13:06 GMT
Lines: 61
msohn...@novell.co.uk (Martin Sohnius) writes:
> Unix clocks start at 00:00 GMT (as it was then called) on 1970 Jan 1.
Perhaps _some_ Unix clocks start on that date, I think the more popular
ones start in 1901. For example, on Solaris 2.3 (sparc), `zdump -v'
outputs `Fri Dec 13 20:45:52 1901 GMT' as the earliest time. This
is because time_t is signed.
> why do you need to know whether summer time was in force even last year?
It matters when you're dealing with historical databases, and you'd be
surprised how many people care about these things. For example, a
well-known bug in Ingres causes it to botch the question of whether
summer time was in force last year, and every so often someone
complains about it in comp.databases.ingres. For applications ranging
from medical records to retrospective stock market analysis, it's
important to get dates _and_ times right.
> Put in the current rules and keep the compiled files small. they need to be
> read in and digested by the various library functions. Don't bloat them.
That's bad advice. The full Adelaide rules that I posted go all the
way back to 1885, when Adelaide first switched to standard time; if you
put in just the current rules, you'll handle times before 1990
incorrectly and you will save (on my host, anyway) _zero_ disk space
and main memory. The difference between the sizes of the compiled
files for Adelaide is only 712 bytes -- which happens to be less than a
disk fragment -- and the programs that read those tables have fixed
size buffers that are already much bigger than the full Adelaide
table. I haven't bothered to measure the difference in CPU time
between `date' with the full table and `date' with the truncated table;
the difference would be so small that it would be hard to measure.
> Anyone contemplated the fact that before 1928 or thereabouts, Astronomical
> Time changed the date at noon? Feel like implementing TZ=:Astronomy?
That change didn't affect civil time, which is what we're talking about here.
>PPS. What ever happened to leap seconds?
The current Olson code and database supports leap seconds.
This hasn't been picked up by many vendors, since the Posix
committee (in one of its more chuckleheaded decisions) mandated
that a host must behave as if leap seconds don't exist.
In response, the Olson code has a compatibility mode contributed by
Bradley White of CMU, in which the actual clock works correctly, but
you can inquire about the time in Posix mode and get the wrong answer
that Posix requires; but this seems to be too complicated for many vendors.
(It's sort of like dealing with DOS time-of-day clocks, in its own
funny way.) Some agile vendors ship with leap second support, and I
believe some more forward-looking distributors even have it turned on
by default, but the bigger, slower-moving vendors make you go to some
lengths to use it if they support it at all.
> A UnixWare machine booted in Jan.1970 would be 12 seconds fast today!
Actually, 18 leap seconds have been inserted since January 1972.
Leap seconds didn't exist before then, but I'd guess your hypothetical
machine would be around 20 seconds fast today, unless you converted
it to use the Olson leapsecond code.
Path: bga.com!news.sprintlink.net!hookup!usc!rand.org!edhall
From: edh...@nntp.rand.org (Ed Hall)
Newsgroups: comp.unix.unixware
Subject: Re: Daylight saving time in UW1.1
Date: 9 May 1994 18:42:04 GMT
Organization: RAND Corporation
Lines: 42
Message-ID: <2qm05s$3ra@rand.org>
References: <767043120.AA04204@cswamp.apana.org.au> <Cp9x6n.7uB@novell.co.uk>
<Cp6IvD.Evy@dsbc.icl.co.uk> <CpAwFA.Lz6@twinsun.com> <CpC896.53r@novell.co.uk>
<CpGx5v.ADL@twinsun.com>
NNTP-Posting-Host: ives.rand.org
X-Newsreader: TIN [version 1.2 PL2]
Paul Eggert (egg...@twinsun.com) wrote:
: msohn...@novell.co.uk (Martin Sohnius) writes:
: > Unix clocks start at 00:00 GMT (as it was then called) on 1970 Jan 1.
: Perhaps _some_ Unix clocks start on that date, I think the more popular
: ones start in 1901. For example, on Solaris 2.3 (sparc), `zdump -v'
: outputs `Fri Dec 13 20:45:52 1901 GMT' as the earliest time. This
: is because time_t is signed.
That's negative time. The "epoch" is 1970 Jan 1 UTC, as Martin said. The
reason time_t is signed is so time values can be compared with simple
arithmetic, not so they can represent pre-1970 dates (which would break
such computations). Some folks have noticed that time_t is signed, and
decided to make time go backwards, but I sort of doubt this was Thompson
and Ritchie's intent.
If you want to be pedantic, Unix clocks "start" at 1970 Jan 1 UTC, and
some Unix clocks run both ways from there.
: > Put in the current rules and keep the compiled files small. they need to be
: > read in and digested by the various library functions. Don't bloat them.
: That's bad advice. The full Adelaide rules that I posted go all the
: way back to 1885, when Adelaide first switched to standard time; if you
: put in just the current rules, you'll handle times before 1990
: incorrectly and you will save (on my host, anyway) _zero_ disk space
: and main memory. The difference between the sizes of the compiled
: files for Adelaide is only 712 bytes -- which happens to be less than a
: disk fragment -- and the programs that read those tables have fixed
: size buffers that are already much bigger than the full Adelaide
: table. I haven't bothered to measure the difference in CPU time
: between `date' with the full table and `date' with the truncated table;
: the difference would be so small that it would be hard to measure.
No, I think it's good advice, given that the various ctime(3) routines
are affected. An application might wind up calling them thousands of
times, and even though the timezone information is read in only once,
it still adds processing to every call.
-Ed Hall
edh...@rand.org
Path: bga.com!news.sprintlink.net!sundog.tiac.net!usenet.elf.com!rpi!usc!
howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!rutgers!
ucla-cs!twinsun!eggert
From: egg...@twinsun.com (Paul Eggert)
Newsgroups: comp.unix.unixware
Subject: Re: Daylight saving time in UW1.1
Message-ID: <CpKIo1.JDz@twinsun.com>
Date: 10 May 94 03:50:23 GMT
References: <767043120.AA04204@cswamp.apana.org.au> <Cp9x6n.7uB@novell.co.uk>
<Cp6IvD.Evy@dsbc.icl.co.uk> <CpAwFA.Lz6@twinsun.com> <CpC896.53r@novell.co.uk>
<CpGx5v.ADL@twinsun.com> <2qm05s$3ra@rand.org>
Sender: use...@twinsun.com
Organization: Twin Sun Inc, El Segundo, CA, USA
Lines: 50
Nntp-Posting-Host: tattoo
edh...@nntp.rand.org (Ed Hall) writes:
> The reason time_t is signed is so time values can be compared with simple
> arithmetic, not so they can represent pre-1970 dates
Unsigned values can be compared just as quickly as signed values --
it's a single machine instruction in both cases, on any architecture in
current use.
> Some folks have noticed that time_t is signed, and
> decided to make time go backwards, but I sort of doubt this was Thompson
> and Ritchie's intent.
I doubt whether they cared all that much, but K&R _did_ make time_t signed.
Most vendors these days treat negative time_t values as
times before 1970, since it's the natural interpretation.
(The only other possible interpretation is to make them illegal,
which causes its own set of problems.)
The relevant standards (ANSI C, Posix) don't state whether time_t is signed,
but all vendors that I know of have followed K&R's lead and kept time_t signed.
> An application might wind up calling them thousands of
> times, and even though the timezone information is read in only once,
> it still adds processing to every call.
Come on, the overhead here is negligible in any realistic application.
Let's take an extreme worst case. Suppose a programmer came to me
and said, ``My application invokes `time(&t), ctime(&t)' 1000 times
per second, and using the full Adelaide table costs an extra 200
microseconds per ctime() call, so I'll get a 25% speedup by going with
the truncated table, and besides I *know* that no program on my host
will ever need to handle dates before 1990 properly, so I want to use
the truncated table.'' Then my answer would be:
1. Why are you invoking `ctime' 1000 times per second?
Isn't it a lot cheaper to invoke it at most once per second,
and cache the result? This will speed up your program
far more than truncating the Adelaide table would, and it
will speed things up even with less complicated time zone rules.
2. How do you know that no other program on your host needs to
handle dates before 1990 properly? If you're not sure, then
perhaps you should create a truncated table just for your
application, while keeping the full table as the default.
This is easy to do with environment variables
(e.g. TZ=':/full/path/to/truncated/Adelaide/table').
3. Really, your best bet is to leave well enough alone,
and stick with the correct time zone table rather than mangling it.