marmen@bwdla31.bnr.ca (Rob Marmen 1532773) (03/26/91)
I need a quick, simple answer to the following question: Does TZ set the timezone correctly under sr10.3? It's that time of the year again, and I was verifying that TZ still changed the timezone on the workstation. It does, but does seem to affect the output of the DATE command. I thought that this command worked at one time, but I could have been mistaken. Anyway, am I wrong, or do I tell my users that they have to do a SHUTDOWN and an EX CALENDAR to reset the time? rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs |
hanche@imf.unit.no (Harald Hanche-Olsen) (03/27/91)
In article <1991Mar25.202013.27817@bwdls61.bnr.ca> marmen@bwdla31.bnr.ca (Rob Marmen 1532773) writes:
I need a quick, simple answer to the following question:
Does TZ set the timezone correctly under sr10.3?
Yes, it does for me:
# date
Tue Mar 26 19:02:26 MET 1991
# tz 2:00 MED
# date
Tue Mar 26 20:03:22 EET 1991
# tz
Timezone: MED
Delta from UTC: 2:00
# tz 1:00 MET
It's that time of the year again, and I was verifying that
TZ still changed the timezone on the workstation. It does,
but does seem to affect the output of the DATE command.
And so it should! However, as the above example shows, the date
command apparently uses some internal table for delta -> timezone name
conversion, hence making it look like I moved to Eastern Europe just
bacause I asked for DST. Is this the effect you were talking about?
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYrees@pisa.citi.umich.edu (Jim Rees) (03/27/91)
In article <1991Mar25.202013.27817@bwdls61.bnr.ca>, marmen@bwdla31.bnr.ca (Rob Marmen 1532773) writes:
Does TZ set the timezone correctly under sr10.3?
Maybe. You probably still have to reboot after running tz, although this
may have been fixed by now. You don't have to run offline calendar.
Aegis (if I may use that term) considers daylight offset to be part of the
timezone. Unix considers it to be a separate offset that gets added to your
timezone, and tries (unsuccessfully) to determine for each timezone which
part of the year this offset should apply. This effort is doomed to failure
due to the unpredictable nature of politicians in most countries. It
sometimes works in some parts of the US (Murray Hill and Berkeley), but is
guaranteed to fail in Arizona, Australia, Singapore, etc.
The Aegis approach is the right one, but since it's not Just Like Real Unix,
nobody likes it.
Note that Unix timezone offsets are backwards from standard convention; west
of Greenwich is positive offset, east is negative. This means the offset
must be subtracted from the system clock to get local time.