Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!ucbvax!ucdavis!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Time Zones; V5N3
Message-ID: <3906@ut-sally.UUCP>
Date: Thu, 2-Jan-86 10:03:27 EST
Article-I.D.: ut-sally.3906
Posted: Thu Jan 2 10:03:27 1986
Date-Received: Thu, 2-Jan-86 22:19:04 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 215
Approved: j...@sally.UUCP
Date: Wed, 1 Jan 86 18:39:26 est
From: seismo!cbpavo.cbosgd.ATT.UUCP!m...@sally.UTEXAS.EDU (Mark Horton)
The latest draft asked for input about time zones. I'd like to
make a few comments.
There are two basic ways that time zones are done today. There
is the V7 method (where the zone offset is in the kernel) and the
System III method (where the zone offset and name is in an environment
variable.) 4.2BSD descends from V7 (although it has a fancier "offset
to zone name" conversion algorithm that knows more about the world)
and System V descends from System III.
There are elegance considerations (e.g. should the kernel know or
care about time zones?) and efficiency considerations (e.g. is it
faster to look in the environment, do a system call, or read a file.)
But both of these are dwarfed by a much more important consideration:
does it work properly in all cases? I claim that neither method is
correct all the time, but the V7 method is right more often than the
System III method.
In V7, when you configure your kernel, you tell it the zone offset,
in minutes, from GMT, and whether you observe Daylight time. These
numbers are stored in the kernel, which doesn't do anything with them
except return them when an ftime system call asks for them. So, in
effect, they are in the kernel for administrative convenience. (You
don't have to open a file, and they aren't compiled into ctime, so it
isn't necessary to relink every program that calls ctime or localtime
when you install a new system.) The smarts that generate the time zone
name and decide if Daylight time is in effect are in ctime in user code.
(By comparison, in TOPS 20, the equivalent of ctime is a system call,
with lots of options for the format. This may seem inelegant, but it
results in only one copy of the code on the system, even without shared
libraries.)
In System III, the kernel doesn't know about time zones at all. The
environment variable TZ stores both the zone names and the zone offset,
and ctime looks there. This makes things very flexible - no assumptions
about 3 character zone names, and it's easy for a person dialing in from
a different time zone to run in their own time zone. Also, it's very
efficient to look in the environment - faster than a system call.
However, there are some very serious problems with the System III method.
One problem is that, with an offset measured in hours, places like
Newfoundland, Central Australia, and Saudi Arabia, which don't have
even hour time zones, are in trouble. But that's easy to fix in the standard.
The time zone is configured into the system by modifying /etc/profile,
which is a shell script of startup commands run by the Bourne shell when
any user logs in, much like .profile or .login. This means that we assume
everybody is using the Bourne shell. This is a false assumption - one of
the documented features of UNIX ever since V6 is that the shell is an
ordinary program, and a user can have any shell they like. In particular,
the Berkeley C shell does not read /etc/profile, so all csh users don't get
a TZ variable set up for them in every System III or V UNIX I've ever used.
Well, after all, the Bourne shell is the standard shell, and everybody should
use the standard shell, right? After all, the new Korn shell reads and
understands /etc/profile.
Even if we believe the above statement and ignore the documented feature
of being able to put your favorite shell in the passwd file (and I don't)
we still get into trouble. For example, uucp has a special shell: uucico.
It doesn't read /etc/profile. And what about programs that don't get run
from a login shell? For example, all the background daemons run out of
/etc/rc? Or programs run from cron? Or from at? Or programs run while
single user? None of these programs get a TZ.
Does it matter if a non-interactive program is in the wrong time zone?
After all, the files it touches are touched in GMT. The answer is yes:
background processes generally keep logs, and the logs have time stamps.
For example, uucico gets started hourly out of crontab, and this means
that almost any uucico on the system (from crontab or from another system
logging in) will run in the wrong time zone. Since L.sys has restrictions
on the times it can dial out, being in the wrong time zone can cause calls
to be placed during the day, even if this is supposedly forbidden in L.sys.
Also, of course, things like "date > /dev/console" every hour from crontab
will have problems.
It turns out that System III has a "default time zone" which is used by
localtime if there is no TZ variable. On every version of System III or
V I've ever used, this is set to the time zone of the developer. It's
EST in the traditional versions from AT&T. It's PST in Xenix. So the
developers of the system never see any problems - uucp logs are right,
for example, and csh users still get the right time. Until they ship
the system out of their time zone.
This problem isn't really that hard to fix. You just have init open
a configuration file when it starts up, and set its own environment
from there. (If you're willing to have init open files that early.)
But it turns out there is an even more serious problem with the TZ
environment variable method. It's a security problem. Let's say the
system administrator has configured UUCP to only call out when the
phone rates are low, because the site is poor and can't afford daytime
rates, or to keep the machine load low during the day. But some user
wants to push something through right away. He sets TZ to indicate that
he's in, say, China. Now, he starts up a uucico (or a cu.) The localtime
routine believes the forged TZ and thinks it's within the allowed time zone,
and an expensive phone call is placed. The log will be made in the wrong
time zone too, so unless the SA is sharp, he won't notice until the phone
bill shows up.
The fundamental difference between the two approaches is that the V7
method makes the timezone a per-system entity, while the Sys III method
makes the timezone a per-process entity. While an argument can be made
that users dialing in from other time zones might want their processes
to be in their local time zone, this isn't a very strong argument.
(I've never seen anyone actually do it.) [This is a symptom of a disease
that is affecting UNIX: a tendency to put things in the environment that
are not per-process. David Yost pointed out, for example, that TERM is
not a per-process entity, it's a per-port entity. Berkeley's V6 had a
file in /etc with per-port terminal codes, similar to /etc/utmp, but
we've actually taken a step backwards by putting it into the environment.
Take a look at tset and people's .profile's and .login's to see the
complexity this decision has cost us.]
So anyway, so far I've argued that the System III method is inadequate.
How about the V7 method?
The V7 method doesn't suffer from any of the weaknesses described above.
It does require a system call to get the time zone, which is a bit more
overhead than a getenv, and the kernel doesn't have any business knowing
about time zones. (The same argument could be made that the kernel doesn't
have any business knowing the host name, too, but both System III and
4.2BSD have that information in the kernel, and it works awfully well.)
The weaknesses in the V7/4.2BSD method are in the time zone name
(since it's computed from a table and the offset value) and in the
rule for deciding when DST begins and ends. The second problem is
also present in the Sys III method.
Suppose localtime finds out that the offset is +60, that is, we are
one hour east of GMT. What time zone name do we use? Well, if we're
France, it might be MET (Middle European Time.) If we're in Germany,
it might be MEZ (Mitten European Zeit.) I probably have the specifics
wrong (I doubt that the French tell time in English) but you get the
idea. An offset just specifies 1/24 of the world, and moving north/south
along that zone you can get a lot of countries, each with widely varying
languages and time zone names. Even Alaska/Hawaii had trouble sharing
a time zone. (The mapping in the other direction is ambiguous too, there
has been lots of amusement and frustration from code that thought BST was
Bering Standard Time, when run in England in July and fed the local
abbreviation for British Summer Time. This is why electronic mail and
news standards currently recommend that messages be stamped in UTC.
Or is that UT? Or GMT? Ick.) So far we've survived because there tends
to be a dominant time zone name in each zone where UNIX has appeared, and
source has been present for the places that have to change it. But as UNIX
becomes more popular in places like Africa, Eastern Europe, and Asia, this
will get a lot messier, especially with binary licenses.
The decision about when daylight time begins and ends is more interesting.
If you read the manual page or the code, you'll discover that localtime
knows rules like "the 3rd Sunday in October" and has a table with special
hacks for 1974 and 1975, when the US Congress decided to change things.
This table "can be extended if necessary". Of course, extending the table
means modifying the source and recompiling the world. Might be hard on
all those binary systems, especially the ones without a programmer on staff.
This hasn't been a problem yet, but now Congress is making noises about
moving the dates around a bit. It's a controversial proposal, and I wouldn't
be surprised if they try two or three rules before the pick one they like.
Given all the old releases still out there, and the development time for
a new release, we need about a 2 year warning of such an impending change.
We'll be lucky to get 6 months.
So what do we do about all this? Well, I think the basic requirements are
that
(1) The time zone should be a per-system entity. There should only be
one place on each system where the zone is specified to ensure that
all programs on the system use the same notion of time zone.
(2) The time zone offset, names, and daylight conventions should be
easily configured by the system administrator. We should have a
standard that allows zone offsets in minutes (maybe even seconds,
I don't know how precise Saudi Arabia needs), zone names of arbitrary
length (they are 7 characters in Australia, for example), whether
we use daylight time at all, when daylight time begins, and when it ends.
The latter two must be allowed to vary as a function of the year.
The exact method for doing this isn't clear. We certainly need a configuration
file. But interpreting this file on each call to ctime isn't a good idea.
It would be nice to have /etc/rc look at the source file and plug a simple
interpretation of it into either a binary file or the kernel, but we have
to worry about what happens if the system is up (and processes are running)
when we convert over to or from daylight time. Perhaps cron has to run a
program to update it every hour. You could have cron only run this program
twice a year, but this would require putting the configuration information
into crontab (which doesn't understand things like "3rd Sunday in October")
and would lose if the system happened to be down at conversion time. Also,
the algorithm has to work for dates that aren't this year, e.g. "ls -l" of
an old file.
How much of this does P1003 need to specify? After all, if they are just
specifying sections 2 and 3, then the file format and the method for making
sure things are right should be up to the implementor. Well, at a minimum,
we need ctime and localtime. We also a standard way to get the time zone
name and offset - there is a lot of ifdeffed code out there that either
looks for TZ or calls ftime - and whether daylight time applies (and by
how much) for a given time.
But there's more. When the mood strikes Congress to change the rules and
gives us 2 months notice, it ought to be possible to publish a new table
that everybody with a P1003 system can just type in. It would be nice if
the location and format of this table were standardized. (After all, the
US Congress doesn't set the rules for the rest of the world, and they are
just as subject to having arbitrary bodies with different rules.)
Finally, there needs to be a requirement that the time zone always work.
Some discussion of these issues should be present. Otherwise, some
implementor is going to think that the System III method works adequately.
Mark Horton
Volume-Number: Volume 5, Number 3
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N9
Message-ID: <3928@ut-sally.UUCP>
Date: Mon, 6-Jan-86 19:28:50 EST
Article-I.D.: ut-sally.3928
Posted: Mon Jan 6 19:28:50 1986
Date-Received: Wed, 8-Jan-86 02:00:24 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 94
Approved: j...@sally.UUCP
From: seismo!allegra!druil!...@sally.UTEXAS.EDU
Date: Mon, 6 Jan 86 17:55:22 EST
I strongly oppose using a centralized time zone for each
computer. It is unnecessarily constricting, creates problems
with networking computers together and with daylight savings, and
is not necessary.
The major reason I read in Mark Horton's article for not using
decentralized time zones is that security holes exist with system
programs getting fooled about what time it really is.
The reason they are getting fooled is not because
of the decentralized nature of the time zone setting, but because
they don't keep their internal times in some standard time zone.
I claim that all programs that care about time should keep all
times internally in GMT (or UCT or whatever you want to call it), and
convert from/to local time on input/output. This is, in fact, the
only way they can not be upset when the time zone of the computer
suddenly changes (which in effect it does when daylight savings
comes and goes).
We are running System III. We have a calendar application. Users
were upset when the meetings they had scheduled for 8 am,
(with the onset of DST) appeared for 9 am.
The problem was the application was keeping stuff in local time,
and not being very smart about it.
A simple revision to use GMT instead fixed this problem, with
the application not knowing or caring if DST is in effect or
not.
My understanding of the centralized proposal is that this
would not longer be possible, that the computer itself would
change times when DST started and ended.
Programs are like people; they get jet-lag when crossing
time zones too fast, and for a program one time zone is
too fast, unless a lot of care has been taken in writing it.
What you want is a processor that steadily ticks along with
only slight corrections to the time while running to correct
clock drift. Changing states to kill off running processes,
changing the time, and restarting may be acceptable in most
environments that Unix has run in currently, but we should
not restrict it to these environments. I want to be able
to sell Unix to hospitals, for example.
We have been mostly lucky because savings time changes in the US at
a time when there isn't much going on, and people don't
notice what happens to, say, at and cron when the clock
changes under them, because they don't do much at that
time of day. But with world-wide access to central computers on the
horizon, and in some applications (such as hospitals) this is
changing.
Networks will shortly progress to the state where
a common time shared by all elements is very desirable,
and this might as well be the current world standard GMT.
Such a common time is the only way to prevent ambiguities,
and changing centralized times to compensate for DST
will introduce these ambiguities.
The problem with System III (besides rc not setting
a default TZ that is passed on) is 1) the daylight
algorithm is centralized. You really want an algorithm
on a per process-group basis, that allows people
from multiple countries that have different daylight
savings definitions to call up and get the one suitable
for them. 2) The syntax for the timezone allows only
multiples of hours. Otherwise the problems come from
system programs which use local time, not GMT.
If the system programs were changed to use GMT, then cat'ing
their files out would not show the time in terms that the
System Administrator was used to (unless s/he is located
in GMT). A filter could be used to translate these,
or the SA could get used to reading GMT. With lengthy
networks, the SA should be reading in GMT anyway to
keep from getting confused when troubleshooting problems
with another element on the network that isn't in the same
zone.
I claim that switching to a single centralized timezone
is short-sighted. It may work for most applications
we have now, but it is not the way to go for the future.
Karl Williamson
ATT ISL Denver
ihnp4!druil!khw
303-538-4583
Volume-Number: Volume 5, Number 9
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N10
Message-ID: <3943@ut-sally.UUCP>
Date: Tue, 7-Jan-86 22:45:44 EST
Article-I.D.: ut-sally.3943
Posted: Tue Jan 7 22:45:44 1986
Date-Received: Thu, 9-Jan-86 02:36:59 EST
References: <3928@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 14
Approved: j...@sally.UUCP
Date: Tue, 7 Jan 86 11:10:22 pst
From: usenix!f...@UCBVAX.BERKELEY.EDU (Erik E. Fair)
This is as much a human interface issue as anything else, and I assert
that it is wrong to force a system administrator (or anyone else) to
think in other than his own time zone. The only exception to this rule
that I can imagine is in networking, wherein it is easiest if all
timestamps are in GMT (or some other absolute measure) so that
calculation of the relative times of various network wide events is
simpler.
Erik E. Fair ucbvax!fair f...@ucbarpa.berkeley.edu
Volume-Number: Volume 5, Number 10
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!
seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N11
Message-ID: <3945@ut-sally.UUCP>
Date: Tue, 7-Jan-86 23:18:02 EST
Article-I.D.: ut-sally.3945
Posted: Tue Jan 7 23:18:02 1986
Date-Received: Thu, 9-Jan-86 03:01:01 EST
References: <3928@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 80
Approved: j...@sally.UUCP
Date: Tue, 7 Jan 86 16:56:17 est
From: seismo!cbpavo.cbosgd.ATT.UUCP!m...@sally.UTEXAS.EDU (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus
>What you want is a processor that steadily ticks along with
>only slight corrections to the time while running to correct
>clock drift.
Exactly. This is what UNIX does now, and I am not suggesting
any changes to this behavior. What V7 does is keep internal
time as time_t in GMT, and next to it are a couple of flags
representing offset from GMT and a daylight flag. These two
flags don't affect the time(2) call, they are just passed to
the ctime(3) routine when it asks the kernel for them with ftime(2).
The local time is then calculated, taking these into account.
>I claim that all programs that care about time should keep all
>times internally in GMT (or UCT or whatever you want to call it), and
>convert from/to local time on input/output. This is, in fact, the
>only way they can not be upset when the time zone of the computer
>suddenly changes (which in effect it does when daylight savings
>comes and goes).
What do you mean "keep all times internally"? If you're referring to
such things as the L.sys UUCP database, I think it's obvious that this
has to be in local time (not only because of the potential for human
error otherwise, but because you'd have to change it by hand every time
you go into or out of daylight time if it were in GMT.) If you're
referring to local timestamps, then certimely a time_t (seconds since
Midnight, Jan 1, 1970, GMT) is a good way to do this, if you don't have
to represent dates before 1970, like birth dates.
>My understanding of the centralized proposal is that this
>would not longer be possible, that the computer itself would
>change times when DST started and ended.
Not at all. What changes is the way the time is displayed to users,
displayed in log files, and interpreted when a user inputs a time.
Clearly such uses should be in the local time zone. (Whether this means
"local" for the machine or for the user is apparently an open issue.)
I gather you are not suggesting that you have a need for a particular
process (or user) to indicate he's in a different time zone from the
system default, although apparently at least one other person has
indicated that on MULTICS people do this. I wonder if anybody uses
this ability on UNIX?
>We have been mostly lucky because savings time changes in the US at
>a time when there isn't much going on, and people don't
>notice what happens to, say, at and cron when the clock
>changes under them, because they don't do much at that
>time of day. But with world-wide access to central computers on the
>horizon, and in some applications (such as hospitals) this is
>changing.
If I were running a 24 hour critical application, such as a hospital,
I would demand that all time logs be 100% correct. Since the real
clock jumps forward or backward by an hour twice a year, the logs had
better do this too (and include the time zone so you can tell if 2:30 AM
was the first or second 2:30 that night.). UNIX already does this quite
nicely (at least in the USA, until Congress decides to change the rules.)
Mark
[ A couple of readers have taken the moderator to task for posting
the article to which Mark replies here, since it was clearly based
on a misunderstanding both of what Mark proposed and what UNIX does.
I posted it because I thought it would give Mark a good opportunity
to clarify the points on which both that and a previous article showed
confusion. I believe he does so ably here. However, I will probably
be more strict in the future in winnowing such submissions as the one
to which he is replying.
I solicit further input on this as well as any other thoughts by
readers on how moderation is done in this newsgroup. For instance:
the V5N11 is in the Subject line because one notes reader wanted it
there; yet another notes reader complains that it interferes with the
subject kill capability of notes. Other opinions? -mod ]
Volume-Number: Volume 5, Number 11
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!utcs!mnetor!lsuc!pesnta!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: How does Saudi Arabia handle time zones?
Message-ID: <4012@ut-sally.UUCP>
Date: Sat, 18-Jan-86 18:35:59 EST
Article-I.D.: ut-sally.4012
Posted: Sat Jan 18 18:35:59 1986
Date-Received: Sun, 19-Jan-86 07:44:26 EST
Reply-To: m...@cbpavo.cbosgd.ATT.UUCP
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 41
Approved: j...@sally.UUCP
Date: Tue, 14 Jan 86 12:04:40 est
>From: seismo!cbpavo.cbosgd.ATT.UUCP!m...@sally.UTEXAS.EDU (Mark Horton)
In the context of standardizing the handling of time zones for UNIX,
the question has arisen: is a timezone offset in minutes good enough,
or does someone need to be able to say "We're at 2 hours, 14 minutes,
and 23 seconds east of GMT"?
I've noticed that most places in the world are on standard
time, and the offsets are either whole hours or half hours.
However, I understand that Saudi Arabia is on "solar time",
which I take it means that the time zone is based on the
exact position of the sun for each town. I also understand
that there may be other countries that don't use standard time.
I'd appreciate a note from anyone who is familiar with the time
zone customs of such countries. What I'd like to know is:
(1) Are offsets always to the nearest minute, or are they sometimes
done to the nearest second?
(2) Are any means taken to compensate for the fact that the Sun is
sometimes up to 8 minutes fast or slow? That is, does the clock run
faster or slower at certain times of the year?
(3) How accurate are times? In official places (such as telephone
companies, airports) that make real use of clocks, are clocks expected
to be correct right down to the second, or are errors of a minute or
so typical? (Even in the USA, people's wristwatches and wall clocks
are usually off by a few minutes, but computers can now synchronize
their clocks to WWV.)
(4) How important is the accuracy of the time? Is it a major religious
ritual to have the time accurate down to the millisecond, or does somebody
just set the clock from a sundial and hope it's within 10 minutes?
Thanks in advance for replies. I'll summarize later to mod.std.unix.
Mark Horton
Volume-Number: Volume 5, Number 19