Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site asgb.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!bmcg!asgb!nkn
From: n...@asgb.UUCP
Newsgroups: net.unix-wizards
Subject: TZ in Other Countries
Message-ID: <561@asgb.UUCP>
Date: Fri, 26-Oct-84 18:10:11 EST
Article-I.D.: asgb.561
Posted: Fri Oct 26 18:10:11 1984
Date-Received: Sun, 28-Oct-84 06:34:15 EST
Organization: Burroughs Corporation, Boulder Colo.
Lines: 23
NOTE:
The following refers to AT&T's UNIX(tm). It may or may not also
apply to Berkeley versions.
I would like to know how UNIX installations outside of the U.S.A.
manage Day Light Savings in their ctime(3C) routines. There is code in
tzset() (which is called by all of the ctime routines) to move the clock
ahead (back) at the appropriate time of the year.
I know that some other countries move their clocks at different
times of the year from us. Also, some countries have time zones which
are not in hour jumps, but increments of 15 or 30 minutes. I am very
curious as to how UNIX sites outside of the U.S.A. have accommodated the
assumptions built into ctime. If you haven't had to modify ctime because
the assumptions work in your country, I'd also be interested in hearing
that.
Please mail me your responses; it's probably not worth cluttering
up the net just to satisfy my curiosity.
As usual, thanks in advance.
Neil Nelson
Burroughs Advanced Systems Group
. . .!sdcsvax!bmcg!asgb!nkn
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: TZ in Other Countries
Message-ID: <221@rlgvax.UUCP>
Date: Mon, 29-Oct-84 18:18:12 EST
Article-I.D.: rlgvax.221
Posted: Mon Oct 29 18:18:12 1984
Date-Received: Fri, 2-Nov-84 02:44:59 EST
References: <561@asgb.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 55
> NOTE:
> The following refers to AT&T's UNIX(tm). It may or may not also
> apply to Berkeley versions.
>
> I would like to know how UNIX installations outside of the U.S.A.
> manage Day Light Savings in their ctime(3C) routines. There is code in
> tzset() (which is called by all of the ctime routines) to move the clock
> ahead (back) at the appropriate time of the year.
> I know that some other countries move their clocks at different
> times of the year from us....
This is one thing that 4.2 has worked on; AT&T should pick it up (preferably
intact, unless they've got one that's *significantly* better - no reason
to be different from 4.2 just for the sake of being different). Instead of
a binary "daylight savings time is in use here" flag, there's a "type of
daylight savings time" flag. A value of 0 means no DST, and a non-zero
value selects one of several tables indicating the start and end of DST.
> Also, some countries have time zones which are not in hour jumps, but
> increments of 15 or 30 minutes.
AT&T should put in a trivial fix to this; they should permit the time zone
offset to be of the form "hours:minutes", such as
QST7:30QDT
where Quahog Standard Time is 7 hours 30 minutes away from GMT.
While they're at it, they should provide a way of getting the time zone
other than from the TZ environment variable, because
1) It's a royal pain in the *ss to make sure every program has the TZ
variable set; putting in /etc/profile is *not* sufficient, as not all
login shells are Bourne shells that read /etc/profile! Furthermore,
in a vanilla S3 system (and, I think, a vanilla S5 system), setting
the environment of the "getty" command doesn't help because "login"
blows away its environment and replaces it with a freshly-crafted one
that doesn't have TZ (or TERM, thus forcing you to set TERM every time
you log in, even if the system knows that you're logging in from the VT100
at your desk).
2) You can fool programs like "uucp" into making calls to other systems
outside of the hours specified in the L.sys file by faking the time zone
offset. (Thanks to Mark Horton for poiinting this one out.)
Getting it from the OS, as was done in V7, would be nice; either it could
be set at sysgen time, or by a system call or just a command which writes on
/unix and /dev/kmem. If TZ is present, it'll use that, otherwise it'll use
the value from the OS (rather than the hardcoded EST5EDT that it currently
uses if TZ is missing). Programs which don't want TZ faked out can do
a "putenv" to stomp on TZ (making it a null string, say), and the "ctime"
routines should use the value from the OS.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy