Newsgroups: comp.sys.sgi.bugs
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uunet!munnari.oz.au!
mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!vislab.su.edu.au!ben
From: b...@vislab.su.edu.au (Ben Simons)
Subject: TZ TIMEZONE BUG for Southern Hemisphere
Message-ID: <CGB0Du.Bs7@ucc.su.OZ.AU>
Keywords: TZ TIMEZONE
Sender: n...@ucc.su.OZ.AU
Nntp-Posting-Host: lewis.vislab.su.edu.au
Reply-To: b...@vislab.su.edu.au
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
useful.
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.
_______________________________________________________
Ben Simons Physics Building, A28,
VisLab Systems Manager Sydney University. NSW.
Phone +61-2-692-3005 AUSTRALIA. 2006.
#
# TIMEZONE file. (Distributed via "rdist" from stacey.vislab.su.edu.au)
#
# MUST BE UPDATED ANNUALLY.
#
# 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
# TZ=EST10EDT
#
# 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]
#
TZ="EDT-11EST-10;65/2:00,304/2:00"
Newsgroups: comp.sys.sgi.bugs
Path: gmd.de!xlink.net!howland.reston.ans.net!agate!library.ucla.edu!harpo!
ucla-cs!twinsun!eggert
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: TZ TIMEZONE BUG for Southern Hemisphere
Message-ID: <CGIyCz.DBJ@twinsun.com>
Keywords: TZ TIMEZONE
Sender: use...@twinsun.com
Nntp-Posting-Host: tori
Organization: Twin Sun Inc, El Segundo, CA, USA
References: <CGB0Du.Bs7@ucc.su.OZ.AU>
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 (:-).