std-unix@ut-sally.UUCP (Moderator, John Quarterman) (03/06/86)
Date: Tue, 4 Mar 86 16:02:04 PST
From: Snoopy <seifert%hammer.uucp@CSNET-RELAY.ARPA>
Once upon a time, I posted a survey, asking which method people
would prefer for allowing a user to override the system default
timezone. I suggested a ~/.daterc file, and/or environment variables.
I received 15 replies. The summary of votes is:
environment variables - 4 votes
either - 3 votes
"not ~/.daterc" - 1 vote
use GMT for everything - 1 vote
"take it out of the kernel and put it in libc" - 1 vote
other - 1 vote
misunderstandings - 4 (at least)
A number of people were concerned with performance, since lots of
programs use timestamps. They were concerned that opening a file
would slow things down.
Some selected replies, edited for brevity:
------------------------------------
From: ihnp4!cbosgd!cbpavo.cbosgd.ATT.UUCP!mark
System V has a default (which always
seems to be the time zone of the developers of the system, so that
the developers will never find any bugs that only show up in non-default
time zones) and overrides it with the TZ environment variable. This
has some horrible properties:
(1) People who don't use the Bourne shell, and hence don't source
/etc/profile, don't get a TZ. This includes csh and uucico.
(2) Programs run from crontab don't get a TZ.
(3) Programs run single user don't get a TZ.
(4) An individual can change his TZ to defraud the system. For
example, a UUCP L.sys may restrict a certain long distance
call to night hours, but by setting your time zone to some
far off part of the world, you can dial out during the day.
[...]
(1) "time right now" must be fast for logging
(2) "time of some date this year" should be reasonably fast for ls -l.
(3) "time of some date some previous year" can be slow.
Mark
----------------------------------
From: hp-pcd!hp-sdd!sdcsvax!bmcg!asgb!devine
My choice looks like:
$TZ=MST-7 # name of timezone and difference from Univeral Time
$DST=1 # how much to adjust for DST; ==0 if no DST is used
$DST_START=(when daylight saving starts)
$DST_STOP=(when daylight saving stops)
Bob Devine
Burroughs / Boulder, CO.
-------------------------------
From: sequent!riacs!seismo!ut-sally!cyb-eng!howard
Whatever happened to the concepts of dynamic linking, true interprocess
communication, and "lightweight processes"? If your operating system
is frozen or hostile and you care about D.S.T., then dynamically loading
a library module might be appropriate. If the o.s. is frozen/hostile and
you don't care, use something like "/etc/daterc" which can be overridden
by $TZ. If you're writing/modifying an o.s., consider dynamically-loaded,
reentrant library routines and memory management hardware to support it.
Of course, a more practical o.s. approach would be to have a date server:
just set up a socket to your favorite date-server port and go get it.
------------------------------------
From: tektronix!allegra!clyde!watmath!utzoo!ecrhub!ecr1!peterc
In studying this problem a while ago, I found I needed three environment
variables. They could have been encoded into one, of course, but that
makes it harder for the user to set up right. I found the following
were necessary:
TIMEZONE: a comma-separated list of the time zones that apply.
e.g. TIMEZONE=EST,EDT
TIMEDIFF: a comma-separated list of the number of minutes west of GMT (east if
negative) the corresponding time zone is.
e.g. TIMEZONE=480,540
TIMECHG: a comma-separated list of the dates on which time changes occur.
It is assumed that at midnight on January 1st each year, we
are in the initial time zone (e.g. EST), and then progress
through the others in sequence, then backwards to the original.
The time change dates are specified in the form
mm/dd+n
where "mm" is the month (1-12), "dd" is the day (1-31), and
the "+n" (or "-n") causes that date to be moved forward
(backward) to the appropriate day of the week (e.g. 4/24+0
means the first Sunday on or after April 24th).
I prefer environment variables for reasons of speed. However, the current
UNIX scheme is not adequate, for several reasons:
- it does not provide the flexibility needed, because everything
is hard-coded.
- it does not satisfy the real-world requirements. In particular,
it does not take into account things like the double
daylight savings time used in much of Europe.
Even the scheme I propose here is not really adequate, because it only accounts
for the current year, which may not be suitable for other years. A more general
scheme could be built by adding special cases for unusual years:
TIMECHG=4/24+0,10/25+0;1974-1975:.....;.....
I.e. make the first set of values (up to the first ';') the rule that applies
in the current year, and any other unspecified year. Then add special cases
for other years.
All this starts to get complex, ugly and unpleasant to set up and program.
That is the way it is. Sir Stanford Fleming established a wonderful system
when he defined Standard Time. I hope he didn't expect it to stay that way.
------------------------------
This is getting prettty long, so I'll describe what I'm actually doing in
a future article.
Snoopy
tektronix!tekecs!doghouse.TEK!snoopy
Volume-Number: Volume 5, Number 66