Tech Insider					     Technology and Trends

			      USENET Archives

Newsgroups: comp.sys.sgi.bugs
From: (Ben Simons)
Subject: TZ TIMEZONE BUG for Southern Hemisphere
Message-ID: <>
Organization: VisLab - Sydney University, Australia.
Date: Thu, 11 Nov 1993 01:34:41 GMT
Lines: 65

Hi all,

    I know that this is going to seem pretty boring to most
    of you, but I post this in case someone else finds it 

There is a bug in the way that "date" determines whether
we are in daylight-savings or not. In the southern hemisphere
(eg: for this year) we go INTO daylight savings (DST) now, and 
come out of it next year (it's spring right now). The problem 
is that the test to see if today should be in DST  

if ( start_DST < today < end_DST )

assumes that start_DST < end_DST, which is not true for us.

The fix is to swap the order of the timezones, so that in a sense
we are always in daylight-savings, and then we go in and out of
our standard time zone. 

FYI Here's a copy of VisLab's /etc/TIMEZONE (incl. below)

Ben Simons                      Physics Building, A28,
VisLab Systems Manager          Sydney University. NSW.
Phone +61-2-692-3005            AUSTRALIA. 2006.

# TIMEZONE file. (Distributed via "rdist" from
# Note that this format for the setting of TZ does not
# (and cannot) allow for Daylight-Savings adjustments
# for NSW timezones. This is because SGI uses the JULIAN DATE
# (ie: a day-number between 0 and 365) to determine when to adjust the time.
# In NSW, we use the "first sunday in march" and the "last sunday in october",
# which is a different Julian date each year... Therefore the time will have
# to be manually moved forward and back for each daylight savings adjustment.
# [ben].
# Previous (wrong) settings of TZ have been:
# TZ=EST-11
# TZ=EST10:00:00EDT11:00:00
# There is a bug in the way that "date" determines whether we are currently
# in the daylight-savings timezone or not. I believe that the problem occurred
# because it was written by someone in the northern hemisphere!!
# In NSW we go INTO daylight-savings on the julian day (0-365) 304, and
# come out on day 65 (the following year). Say that today is day 315, then
# the test to see whether we should be in daylight savings is:
# 	if 304 < 315 < 65
# which fails... tsk! So, I've swapped the two zones around as if we are
# always in daylight savings, and then we go into standard time on day 65,
# and leave standard time on day 304. This works.
# Thus "EDT-11EST-10;65/2:00,304/2:00" means Eastern Daylight Time zone is
# -11 hours from GMT, Eastern Standard Time is -10 from GMT, we go into EST
# on julian day 65 at 2:00am, and we leave EST on julian day 304 at 2am.
# [ben 11Nov93]

Newsgroups: comp.sys.sgi.bugs
From: (Paul Eggert)
Subject: Re: TZ TIMEZONE BUG for Southern Hemisphere
Message-ID: <>
Nntp-Posting-Host: tori
Organization: Twin Sun Inc, El Segundo, CA, USA
References: <>
Date: Mon, 15 Nov 1993 08:31:45 GMT
Lines: 5

One of these days SGI should switch to Arthur David Olson's public domain
time zone code, which doesn't have that bug and is a lot easier to use.
Instead of monstrosities like TZ="EDT-11EST-10;65/2:00,304/2:00",
with Olson's code all you need to say in New South Wales is TZ="Australia/NSW".
Sun's been doing it right for years -- perhaps that's why SGI's resisting (:-).

			        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

Electronic mail:			       WorldWideWeb: