Tech Insider					     Technology and Trends


			      USENET Archives

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.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/