Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/mod.std.unix.v5

Internet Message Format | 1987-06-30 | 213KB

From jsq  Wed Jan  1 07:52:12 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 5; V5N1
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 1 Jan 86 13:51:58 GMT
Draft-9: mod.std.unix

This is the first article in Volume 5 of mod.std.unix/std-unix.
These volumes are strictly for administrative convenience.  This
one starts now because I mailed copies of Volumes 3 and 4 to the
P1003 committee chair with my ballot on the Trial Use Standard
(I'm the representative of USENIX on the P1003 committee).
Paper copies of volumes 1 and 2 had been delivered previously
and several committee members follow the newsgroup on-line.

Feel free to continue any discussions from the previous volume
or to start new discussions.


The USENET newsgroup mod.std.unix is for discussions of UNIX standards,
particularly the IEEE P1003 draft standard.  It is also distributed
in an ARPA Internet mailing list.  I'm the moderator, which mostly
means I post what you send me.

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix

Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

Archives may be found on sally.UTEXAS.EDU.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
as ~ftp/pub/mod.std.unix, while the previous volumes may be retrieved
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc.
The volume with the AT&T public domain getopt(3) is ~ftp/pub/mod.std.unix.v3.

Finally, remember that any remarks by any committee member (especially
including me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of the standard) of the committee as a
whole, unless explicitly stated otherwise in such remarks.

Volume-Number: Volume 5, Number 1

From jsq  Wed Jan  1 08:15:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to P1003 Draft 6; V5N2
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 1 Jan 86 14:15:24 GMT
Draft-9: D6.Access

I've been getting questions about how to get copies of P1003.D6,
so here are the directions once again.

Balloting on Draft 6 as the Trial Use Standard just completed
and resolution of the ballots will continue at least through the
P1003 meeting in Denver just before the Denver USENIX this month.


An online document which "represents" P1003 Draft 6 is on sally.UTEXAS.EDU
for retrieval by anonymous ftp (connect with ftp, log in as anonymous
with password guest) over the ARPA Internet.  The files are:

-rw-r--r--  1 jsq      bin        419840 Nov 27 21:48 ~ftp/pub/P1003.D6
-rw-r--r--  1 jsq      bin        376814 Nov 27 21:50 ~ftp/pub/P1003.D6.doc
-rw-r--r--  1 uucp     uucp       141981 Nov 22 17:37 ~ftp/pub/P1003.D6.Z
-rw-r--r--  1 uucp     uucp       124055 Nov 24 01:31 ~ftp/pub/P1003.D6.doc.Z
-rw-r--r--  1 jsq      bin           512 Dec  1 11:26 ~ftp/pub/P1003.D6.run

P1003.D6 is a tar archive of the source for the document.
P1003.D6.doc is an nroff formatted copy of the document, suitable
    for printing on a line printer (contains form feeds and backspaces).
P1003.D6.Z and P1003.D6.doc.Z are compressed copies of the above files.
They were compressed with compress version 4, a public domain program
which has been distributed over newsgroup net.sources on USENET.
There is a copy on sally.UTEXAS.EDU in ~ftp/pub/compress.shar.

P1003.D6.run is a replacement for the run script in the archive,
which was for local use on decvax.  You will still need to adapt
it to your printer if it's not an ln01.

The list of hosts which previously made Draft 5 available are
sally.UTEXAS.EDU, as above; on UUCP:  ut-sally (contact ut-sally!jsq),
decvax (contact decvax!jmcg), l5, seismo, ucbvax, munnari, and enea.
Presumably they will all pick up at least the compressed files.

Those of you who have asked for copies by UUCP mail:  I've found
a method; please contact me again if you're still interested.
If you're on the ARPA Internet you should use ftp.

The rest of this article is a note which appears in the document:


This online document represents, but IS NOT, the current DRAFT (Draft 6,
produced 15 November 1985) of the IEEE Computer Society's P1003 Working
Group for a "Portable Operating System Environment" based on the UNIX
Operating System (Trademark of AT&T Bell Laboratories).

This material is copyright of IEEE, with ALL RIGHTS RESERVED.  Please
respect these restrictions so we can continue to offer on-line access to
the information.

If you want to join the Correspondent Group (don't expect to make
meetings), the Working Group, or Balloting group for this standards
effort please contact:

     Jim Isaak             decvax!frog!jim
     Charles River Data Systems
     983 Concord Street
     Framingham, MA  01701.

(Jim needs your US Mail address to send you information about the effort;
he also needs your IEEE Membership Number if you wish to join the Balloting
Group).

Draft 6 was prepared for the Trial Use Balloting now taking place, with
a final use ballot some time near the end of 1986.

A moderated USENET group exists for on-line discussion of this effort
under the name: mod.std.unix

If you want hard copies of the DRAFT, you can obtain these from:

    Beth Cummings
    IEEE Standards Office;
    345 E. 47th Street
    New York, NY  10017


Volume-Number: Volume 5, Number 2

From jsq  Thu Jan  2 09:03:52 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Time Zones; V5N3
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 2 Jan 86 15:03:27 GMT
Draft-9: TZ

Date: Wed, 1 Jan 86 18:39:26 est
From: seismo!cbpavo.cbosgd.ATT.UUCP![e-mail] (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

From jsq  Fri Jan  3 20:02:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Time Zones; V5N4
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Jan 86 02:02:33 GMT
Draft-9: TZ

Date: Fri, 3 Jan 86 11:22:50 pst
From: usenix!fair@@sally.UTEXAS.EDU (Erik E. Fair)

I want to amplify what Mark Horton had to say, and also point out one
more little gotcha in the System III/System V method of timezone
keeping:

There are quite a few programs that purposely zap the environment for
security reasons (e.g. uucico, uuxqt, getty, login), which have to be
modified to pass through TZ (in addition to PATH, LOGNAME, etc.) to
their children, if you want to get your time stamps right for the zone
you're in (unless you're lucky enough to be in the default zone, or
have the unmitigated gall to set the default to your local time zone,
like AT&T).

In particular, uuxqt has to be fixed because the mail program is
invoked as a child of uuxqt, and thus inherits uuxqt's environment.

    still mad about this nearly two years later,

    Erik E. Fair    ucbvax!fair    [e-mail]

Volume-Number: Volume 5, Number 4

From jsq  Fri Jan  3 20:04:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N5
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Jan 86 02:04:43 GMT
Draft-9: TZ

Date: Fri, 3 Jan 86 09:52:13 est
From: harvard!encore!babel![e-mail] (P. Tucker Withington)

In Mark's comments about time zones the only "insurmountable" problem he
found with the Sys III method was his security hole, that a user could
force uucp's L.sys table to be interpreted incorrectly.

The real problem is that the L.sys entry is ambiguous, unless a TZ
is given to interpret it.  The solution here is akin to having "init"
set a default time zone.  uucico needs to have a profile that defines
the timezone L.sys is to be interpreted relative to, which overrides any
user setting of TZ.  Alternatively, the L.sys entries could be "fully
specified", including a time zone or defined to be GMT.

The objection to putting TZ in the environment is not specific to TZ,
it is a general problem with the implementation of environment.  (There
probably should be some shared environment, in addition to private
environment, so that "constants" like TERM and TZ are not carried around
as excess baggage by each process.)

I conclude that the System III time zone mechanism is then equal to the
V7 mechanism, with the advantage that each user can operate in whatever
time zone he likes.

Regarding the daylight savings bugaboo:  I feel this is a red herring.
You probably care when the present time is DST, but being off by +/-
1 hour on ancient file dates is not going to really bother anyone.  Thus
it is probably sufficient to have a shell script in your profile to set
any "exceptional" DST times.

Volume-Number: Volume 5, Number 5

From jsq  Sat Jan  4 17:40:02 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N6
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Hokey)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Jan 86 23:39:49 GMT
Draft-9: TZ

From: plus5![e-mail] (Hokey)
Date: Sat, 4 Jan 86 12:21:58 CST

>Date: Fri, 3 Jan 86 09:52:13 est
>From: harvard!encore!babel![e-mail] (P. Tucker Withington)
>
>Regarding the daylight savings bugaboo:  I feel this is a red herring.
>You probably care when the present time is DST, but being off by +/-
>1 hour on ancient file dates is not going to really bother anyone.  Thus
>it is probably sufficient to have a shell script in your profile to set
>any "exceptional" DST times.

This situation is precisely why all timestamps should be kept in GMT.

At the systems level there can be problems with make, backups, and cron,
and at the applications level there can be problems tracking events (this
becomes critical in, for example, health care.  Looks kinda strange when
critical tests are performed, say, a half hour after a patient dies (or
when there is an hour gap between patient admission and performance of the
tests).

[ Make uses the internal system format; I don't believe anyone has argued
that that should be anything but GMT.  It is not clear (at least to me)
that keeping the human-readable presentation formats used by things like
cron in GMT instead of local time will decrease human errors:  people do
mostly think in local time.  -mod ]

--
Hokey           ..ihnp4!plus5!hokey
          314-725-9492

Volume-Number: Volume 5, Number 6

From jsq  Sun Jan  5 10:23:51 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N7
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 5 Jan 86 16:23:40 GMT
Draft-9: TZ

Date: Sun, 5 Jan 86 00:52:37 est
From: seismo!harvard!think!mit-eddie![e-mail] (Barry Margolin)

In response to Mark Horton's posting about time zones:

Multics has long had per-process time zones, and they are extremely
heavily used on systems which have users logging in from across the
country (or world, in some cases).  Most of the people in my Cambridge,
MA office use a system in Phoenix, AZ quite a bit, and I am considered
unusual because I don't bother to set my time zone to EST.

One good argument for only having system zones that was made was about
software that makes critical decisions based on the time of day (the
example was a wrapper for uucico that makes sure the call isn't being
made during the day).  The solution is for such programs to ignore
the TZ inherited from the caller, perhaps using a new system call
that gets the system-default time zone.  We don't have this problem
on Multics because security decisions are either made in daemon processes
or in inner-ring subroutines, and per-process variables are actually
per-process per-ring, so the user's personalization generally doesn't
affect secure domains.

One apparent difference in time zone semantics between Unix and Multics
is the behavior of past/future times.  On Multics, the time zone in which
a date/time should be converted to GMT is an INPUT parameter, defaulting
to the process' time zone; we do not attempt to determine whether DST
was in effect on the date being converted.  We therefore have no need
for complex DST calculation at run time.  Whether this is considered
right or wrong is mostly a matter of taste; I know of a other systems
that have chosen to dynamically determine DST.  In general, a subroutine
for converting a time in a specified time zone to GMT is a useful
facility; for instance, to interpret Date fields in mai headers.

I have been thinking about WHY many systems try to determine the
DST state at a given time.  This is because they only store the binary
form of the time in various system databases, and attempt to display
the user-relative time at which the event took place (for instance,
so that you can tell that it was very late when the user modified
a file, so the bugs are probably because he was tired).  The "right"
way to get this effect would be to store the user's personal time zone
in addition to the binary time.  Display routines would display the
time in the retrieved time zone, rather than trying to guess the appropriate
time zone.  In the context of Unix standardization, this is probably
unreasonable, as it is not consistent with any existing version of Unix.
It also has the problem that it increases the size of times stored in
many system databases, which may be considered wasteful for the little
benefit that this approach provides.
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar

Volume-Number: Volume 5, Number 7

From jsq  Mon Jan  6 08:50:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: What do you call an ex-directory?; V5N8
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Jan 86 14:50:44 GMT
Draft-9: 5.2

Date: Sun, 5 Jan 86 19:14:39 est
From: seismo!allegra!phri![e-mail] (Roy Smith)
Subject: What do you call an ex-directory? (or, "it's not dead, just sleeping")

    This may fall more into the category of a trivia question rather
than something that demands being standardized, but here goes anyway.  Try
the following:

    % mkdir temp
    % cd temp
    % csh
    % cd ..
    % rmdir temp
    % exit
    % pwd

    I just did that on my 4.2 system and got back "/".  If I remember
correctly, the corresponding sequence on version 6, using sh instead of csh
of course, would give you "".  Is there a standard for what getwd() should
return in the face of an error?  Should there be (i.e. is it worth it)?  It
seems to me that the version 6 answer is somehow more accurate, even if it
is not actually any more useful.

Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

Volume-Number: Volume 5, Number 8

From jsq  Mon Jan  6 18:29:03 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N9
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 7 Jan 86 00:28:50 GMT
Draft-9: TZ

From: seismo!allegra!druil![e-mail]
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

From jsq  Tue Jan  7 21:45:55 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N10
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 8 Jan 86 03:45:44 GMT
Draft-9: TZ

Date: Tue, 7 Jan 86 11:10:22 pst
From: usenix![e-mail] (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    [e-mail]

Volume-Number: Volume 5, Number 10

From jsq  Tue Jan  7 22:18:13 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N11
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 8 Jan 86 04:18:02 GMT
Draft-9: TZ

Date: Tue, 7 Jan 86 16:56:17 est
From: seismo!cbpavo.cbosgd.ATT.UUCP![e-mail] (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

From jsq  Wed Jan  8 09:01:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: What do you call an ex-directory?; V5N12
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 8 Jan 86 15:01:20 GMT
Draft-9: 5.2

Date: Tue, 7 Jan 86 22:30:26 MST
From: seismo!hao!boulder![e-mail] (Geoffrey Clemm)
Organization: University of Colorado, Boulder

In article <[e-mail]> Roy Smith writes:

>From: seismo!allegra!phri![e-mail] (Roy Smith)
>Subject: What do you call an ex-directory? (or, "it's not dead, just sleeping")
>I [deleted my current directory] on a 4.2 system and got back "/" frow pwd.
>The corresponding sequence on version 6, using sh instead of csh
>of course, would give you "".
...
>It seems to me that the version 6 answer is somehow more accurate, even if it
>is not actually any more useful.

On a 4.3 system, you get back :

  pwd: getwd: can't stat .

which seems far better than either the version 6 or the 4.2 response.

Geoff Clemm

Volume-Number: Volume 5, Number 12

From jsq  Thu Jan  9 13:11:35 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Time Zones; V5N13
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Davidsen)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Keywords: TZ
Date: 9 Jan 86 19:11:17 GMT
Draft-9: TZ

Date: Thu, 9 Jan 86 11:39:06 est
From: Davidsen <seismo!rochester!steinmetz![e-mail]>
Organization: GE CRD, Schenectady, NY

The recent posting on TZ implementation has prompted discussion at our site,
with the following comments and suggestions:

1) Process TZ is very useful. We use systems in Chicago and Minn, and would
like our times as displayed to be meaningful. We regularly reset TZ in our
.profile on these systems.

2) An extension is needed to handle cases where the TZ offset is not an even
hour, and where the daylight savings time calculation is not the (current) US
standard. We even were so bold as to envision one method of doing this.

The proposed solution is to give a TZ value having no offset, simply a series
of characters as the identifier, as "TZ=PILST". When a TZ without an offset
was located, a directory would be searched for a file with the same name. For
illustration, call this /usr/bin/TZ. When the matching file was executed using
the date for an argument, the correct offset from GMT would be returned in
clock ticks. This value could then be added to the current GMT value to get
"process local" time.

Note: what is important
is that the processes are user (sysmgr) definable to match changing local
laws, etc. I would feel that it is acceptable to require reboot of the system
to change these procedures, so some pointers or even the process itself(?)
could be kept in memory to speed things up.
These routines would have to be executed fairly often, since the
change points of the algorithms might be anywhere. Another suggestion was to
make these routine devices, and install them as device drivers.

The example time zone, PILST, stands for the hypothetical "Pothole IL Local
Standard Time", which is 4:17 ahead of the rest of the state because the clock
in town hall is off by that much. This example is less funny if you look at
the number of entire countries in conventional time zones, particularly those
shared by Eurasia and Africa. Hospitals might want to shift the change to
daylight time by some hours to minimize the posibility of error, and could,
using this solution, have their own "hospital standard time".

The problem of time for uucp and at are not as simple as they seem. If I want
to run a job during off hours, 0100 means 1am, computer time. If I want to
have the system call me back at 3:30pm local time to test a new uucp or
something, I mean my local time. If I make a cron entry to run uucico at a
given time, it uses the default shell timezone, while incoming calls use the
system, since the are not executed under a shell. This confuses the logfiles
no end. One of our sysmgrs keeps the system time at GMT rather than EST5EDT
(for valid reasons, but complex), which really messes up the log. I think the
solution to that would be to have uucico use some known TZ rather than the
inherited TZ (/usr/lib/uucp/TZ anyone?). This would keep the logs consistant.

Obviously the times in L.sys should be to a standard, but should it be local
time or destination time. Since the anther is "both", a TZ field may have to
be added to L.sys, since local time is what I use to control my phone bill,
but destination time is what I use if a remote system is only up for uucp at
certain times.

Hopefully these ideas will inspire some constructive followup.

    -bill davidsen

    seismo!rochester!steinmetz!--\
       /                               \
ihnp4!              unirot ------------->--- crdos1!davidsen
       \                               /
        chinet! ---------------------/

"It seemed like a good idea at the time..."

Volume-Number: Volume 5, Number 13

From jsq  Thu Jan  9 19:11:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: TZ and TERM per process; V5N14
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 10 Jan 86 01:11:09 GMT
Draft-9: TERM TZ

From: ukc!minster!forsyth
Date: Thu, 9 Jan 86 18:03:15 GMT

It can be helpful for TZ to be a per-process value (eg, in the
environment).  For instance, if I am logged in to a computer
several time zones away, with TZ set to reflect my local time,
I might say

    echo "echo go to the pub | write $NAME" | at 7pm

to get a message at 7pm my time, or (in the same session)

    TZ= at 3am <ada-testrun

to cause a long-running job to be started on the remote
system at a little-used time (their time).

Similarly, I might set TERM per process if I wish
to check the output of a supposedly terminal-independent
program for different terminal types:
    TERM=vt100 greeneking | vis
    TERM=520 greeneking | vis
    ...
I might do something similar if running emulators in
different layers, though arguably that might be handled
by the ``per port'' notion.  (Although /etc/ttytype or
whatever is hard pressed to deal with people logging
in on different terminals on the same network or dial-in
port.)

There are other ways of doing these things,
but I find this compositional style more attractive
than, say, -l (local time) or -z (time zone) options
to `at' and other commands.
I'd be interested to see other approaches.

Volume-Number: Volume 5, Number 14

From jsq  Fri Jan 10 20:15:51 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process; V5N15
Message-Id: <[e-mail]>
References: your article <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Jan 86 02:15:40 GMT
Draft-9: TERM TZ

From: seismo!harvard!prime![e-mail] (Steve Glaser)
Date: Fri, 10 Jan 86 18:33:48 est

By the way, another example of a program that uses local time for its logs is
SCCS (and RCS).  I've had cases where I was trying to check something in around
the timezone switch and SCCS wouldn't let me do it (cause the new release
was older than the old release).  I don't know what posessed the folks
at Bell to use local time on this one.


    Steve Glaser
    harvard!prime!steveg

Volume-Number: Volume 5, Number 15

From jsq  Sun Jan 12 10:26:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process; V5N16
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Jan 86 16:26:21 GMT
Draft-9: TERM TZ

[ Let me reiterate something that many people do not seem to realize:
UNIX has *always* kept internal time in GMT; that is not an issue.

Joe Yao's summary below covers most of the actual issues.
If you do not agree with parts (or all) of it, submit your comments.
But no flames please.  This is a technical discussion newsgroup,
not a boxing ring.  -mod ]

Date: Sat, 11 Jan 86 15:08:53 est
From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA

Following this discussion, it is clear that a number of different
things are needed.  We need:
(1) a way to be sure that logs are kept in one, single, system-
    appropriate time;
(2) a way that people can set times reported to them to be meaningful;
(3) a way that people can enter times in a way that is meaningful to
    the system, but also understood correctly by the machine (with at
    or cron or remind as cases in point);
(4) a standard for individual machines to tell (over nets) other
    machines what time they think it is;
(5) perhaps an 'rtime' facility, to know what time it is elsewhere?;
[ Much work has been done on 4 and 5.  I will post a followup article.  -mod ]
(6) a way to be sure that processes can't override system time limits
    by changing the time (such as with UUCP);
(7) a way for system managers to be able to specify either a default
    "time zone" or a way of figuring out (from 0 to infinity) what
    the time really is/was.
Probably several other things, as well.

It's not clear that only one mechanism will take care of all of these.
For instance, agreeing to allow a time zone specifier in input formats
certainly addresses a lot of these.  But, what about "Pothole IL Local
Standard Time" (EST+0:04:17)?  We will need some way to figure out time
zones that are not exactly integral hours off from UCT.  I don't like
particularly the idea of user-written time agents, partly because I
know how often "professional software engineer"s make little (or big)
mistakes, especially in the area of not testing all boundary
conditions, and I can imagine those who aren't constantly engineering
software might make even more.  Perhaps we can figure out a way to
specify the rules for a time zone in a user-writable table, so that
if politicians decide to mess us up even further we can just send a
few lines of table over the net to patch the algorithm.  Note that
the algorithm  s h o u l d  work "from 0 to infinity."

[ It should also work from zero to negative infinity.  -mod ]

                            And, of course,
each process group (or maybe process) might want to have an idea of
what its own expression of time is; but should be able to get at the
system's idea, too.  (Just for Rob Pike, a date -[lsv]?)  As an under-
lying time, of course, it is good to get machines to think and talk
to each other in UCT (GMT), as radio operators do, since that is one
of the things it was invented for!

[ Once more:  internal (kernel) UNIX time format is GMT, and that's also
what has always been used on networks like the ARPANET for communication
between systems, whether UNIX, TOPS-20, Multics, or whatever.  -mod ]

                    It is (so far) independent of
astronomical or political changes in the "real" time.  We'll see how
this works once we start talking in terms of relativistic distances
[;-)].

[note: deference to rob pike, whose talk "cat -v considered harmful"
was actually a good expose' on creeping featurism.  -jsdy-]

[ The talk of that name was originally given at the Toronto (Summer 1983)
USENIX Conference and has an abstract in those proceedings.  A paper in
the same vein is:

          Pike1984.       R. Pike and B. W. Kernighan, "Program Design
                          in  the  UNIX  Environment," [BLTJ1984], pp.
                          1595-1605, 1984.

That journal issue is now selling for a reasonable price, I hear.
(I don't know what the price is or what the telephone number is.)

          BLTJ1984.       BLTJ,   "The   UNIX   System,"   AT&T   Bell
                          Laboratories Technical Journal, vol. 63, no.
                          8, American Telephone and Telegraph Company,
                          Short Hills, N.J., October 1984.

And if you like the article, you'll love the book:  :-)

          Kernighan1984.  Brian W. Kernighan and Rob  Pike,  The  UNIX
                          Programming    Environment,   Prentice-Hall,
                          Inc., New Jersey, 1984.

-mod ]
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}

Volume-Number: Volume 5, Number 16

From jsq  Sun Jan 12 12:00:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: ARPA Internet Time Protocols; V5N17
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Jan 86 18:00:03 GMT
Draft-9:

A wheel that frequently gets reinvented is how to tell the time over networks.
Much work has been done on this subject in the ARPA Internet from back when
there was only the ARPANET up to a few months ago.  This article is a brief
summary of the existing methods.

Herein GMT and UT are used as synonyms for Coordinated Universal Time.

Here is a list of references in (mostly) chronological order, to be followed
by abstracts of or comments on each.  Probably the most widely used protocol
is RFC868.  Possibly the best for what it tries to do is RFC958.  For use
in synchronizing clocks of machines on a local area network, TSP will likely
become increasingly important, because it will come with 4.3BSD.  Several
higher-level schemes employ RFC792.

If there is sufficient interest, I will post the relevant RFCs to mod.sources.

(RFC792) Sep 81    (Postel)      Internet Control Message Protocol
(RFC778) 18 Apr 81 (Mills)       DCNet Internet Clock Service
(RFC867) May 83    (Postel)      Daytime Protocol
(RFC868) May 83    (Postel)      Time Protocol
(RFC956) Sep 85    (Mills)       Algorithms for Synchronizing Network Clocks
(RFC957) Sep 85    (Mills)       Experiments in Network Clock Synchronization
(RFC958) Sep 85    (Mills)       Network Time Protocol
TSP: The Time Synchronization Protocol for UNIX 4.3BSD, R. Gusella and S. Zatti


(RFC792) Sep 81    (Postel)      Internet Control Message Protocol

This is one of the basic protocols of the TCP/IP suite.  It sits on top
of IP and is mostly used for inter-network routing.  However, it also has
a Timestamp message, which is used by several later time applications.
This message allows exchanging time in milliseconds since midnight UT.

(RFC778) 18 Apr 81 (Mills)       DCNet Internet Clock Service

An early use of the ICMP Timestamp messages of RFC792 to synchronize
clocks of machines on a more or less local network.  Superseded by RFC958.

(RFC867) May 83    (Postel)      Daytime Protocol

Allows connecting to a foreign host and receiving the time as an ASCII
character string.  Seldom implemented and little used because there is
no standard for what the character string should be (much less for what
time zone it should be in).


(RFC868) May 83    (Postel)      Time Protocol

The basic Internet time of day protocol for many years.  Quoting:

    This protocol provides a site-independent, machine readable date and
    time.  The Time service sends back to the originating source the time in
    seconds since midnight on January first 1900.

The choice of seconds was deliberate because this protocol was intended to
be used between systems on long-haul networks on which greater precision
would only give an illusion of accuracy.  Sometimes used in conjunction
with ICMP Timestamp messages when communicating with hosts from which
greater accuracy is available.  Best used to poll several hosts and compare
their time before setting the local host's time.

It may be used on top of either TCP or UDP:  UDP is better because of
lessened load on machines running the servers and because of lessened
round trip times.

At least four implementations of this protocol for 4.2BSD exist:

name    author                    anonymous ftp source

rdate    Sun Microsystems Incorporated        none
    Polls one host and believes it if it responds.
    Uses inetd.  Only uses TCP.

ndate    Christopher Kent <[e-mail]> merlin.purdue.edu:dated.flar
    Tries many hosts in succession, believes the first to respond.
    Tries for accuracy by taking round trip delay into account.
    Does not use inetd.  Uses UDP.

nettime    Richard Johnson <[e-mail]>        uci.edu:pub/nettime.c
    Polls many hosts, even broadcasts a request over ethernet.
    Does some averaging and rejection to pick a best time.  Uses UDP.

netdate    John Quarterman <[e-mail]> sally.utexas.edu:pub/netdate.shar
    Polls many hosts, picks the largest group with similar times,
    and believes the first of those.  (The intervals and hosts can
    be specified on the command line for various effects.)
    Uses inetd, with TCP or UDP.


(RFC956) Sep 85    (Mills)       Algorithms for Synchronizing Network Clocks

Covers most of the issues involved.  Here is the first page:

Status of this Memo

   This RFC discussed clock synchronization algorithms for the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Table of Contents

   1.      Introduction
   2.      Majority-Subset Algorithms
   3.      Clustering Algorithms
   4.      Application to Time-Synchronization Data
   5.      Summary and Conclusions
   6.      References
   Appendix
   A.      Experimental Determination of Internet Host Clock Accuracies
   A1.     UDP Time Protocol Experiment
   A2.     ICMP Timestamp Message Experiment
   A3.     Comparison of UDP and ICMP Time

List of Tables

   Table 1.  C(n,k) for n from 2 to 20
   Table 2.  Majority Subsets for n = 3,4,5
   Table 3.  Clustering Algorithm using UDP Time Protocol Data
   Table 4.  Clustering Algorithm using ICMP Timestamp Data
   Table 5.  ISI-MCON-GW Majority-Subset Algorithm
   Table 6.  ISI-MCON-GW Clustering Algorithm
   Table 7.  LL-GW (a) Majority-Subset Algorithm
   Table 8.  LL-GW (a) Clustering Algorithm
   Table 9.  LL-GW (b) Majority-Subset Algorithm
   Table 10. LL-GW (b) Clustering Algorithm
   Table A1. UDP Host Clock Offsets for Various Internet Hosts
   Table A2. UDP Offset Distribution < 9 sec
   Table A3. UDP Offset Distribution < 270 sec
   Table A4. ICMP Offset Distribution < 9 hours
   Table A5. ICMP Offset Distribution < 270 sec
   Table A6. ICMP Offset Distribution < 27 sec
   Table A7. ICMP Offset Distribution < .9 sec
   Table A8. Comparison of UDP and ICMP Host Clock Offsets


(RFC957) Sep 85    (Mills)       Experiments in Network Clock Synchronization

Similar to RFC956, but more about how you get the accurate time in the
first place, before you try to distribute it over the network.
Everything you ever wanted to know about WWV and GOES clocks.

Table of Contents

   1.      Introduction
   2.      Design of the Synchronization Algorithm
   2.1.    The Logical Clock
   2.2.    Linear Phase Adjustments
   2.3.    Nonlinear Phase Adjustments
   3.      Synchronizing Network Clocks
   3.1.    Reference Clocks and Reference Hosts
   3.2.    Distribution of Timing Information
   4.      Experimental Validation of the Design
   4.1.    Experiment Design
   4.2.    Experiment Execution
   4.3.    Discussion of Results
   4.3.1.  On Power-Grid Clocks
   4.3.2.  On Clocks Synchronized via Network Links
   4.3.3.  On the Accuracy of Radio Clocks
   4.3.3.1. The Spectracom 8170 WWVB Radio Clock
   4.3.3.2. The True Time 468-DC GOES Radio Clock
   4.3.3.3. The Heath GC-1000 WWV Radio Clock
   4.3.4.  On Handling Disruptions
   4.4.    Additional Experiments
   5.      Summary and Conclusions
   6.      References

List of Figures

   Figure 1. Clock Registers
   Figure 2. Network Configuration


(RFC958) Sep 85    (Mills)       Network Time Protocol

Not yet a standard but it probably will be.  At least one 4.2BSD implementation
is said to exist but I don't have access information for it offhand.
Quoting from the beginning of the RFC:

Status of this Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Table of Contents

   1.      Introduction
   2.      Service Model
   3.      Protocol Overview
   4.      State Variables and Formats
   5.      Protocol Operation
   5.1.    Protocol Modes
   5.2.    Message Processing
   5.3.    Network Considerations
   5.4.    Leap Seconds
   6.      References
   Appendix A. UDP Header Format
   Appendix B. NTP Data Format

1.  Introduction

   This document describes the Network Time Protocol (NTP), a protocol
   for synchronizing a set of network clocks using a set of distributed
   clients and servers.  NTP is built on the User Datagram Protocol
   (UDP) [13], which provides a connectionless transport mechanism.  It
   is evolved from the Time Protocol [7] and the ICMP Timestamp message
   [6] and is a suitable replacement for both.

   NTP provides the protocol mechanisms to synchronize time in principle
   to precisions in the order of nanoseconds while preserving a
   non-ambiguous date, at least for this century.  The protocol includes
   provisions to specify the precision and estimated error of the local
   clock and the characteristics of the reference clock to which it may
   be synchronized.  However, the protocol itself specifies only the
   data representation and message formats and does not specify the
   synchronizing algorithms or filtering mechanisms.


TSP: The Time Synchronization Protocol for UNIX 4.3BSD, R. Gusella and S. Zatti

I've not been able to locate a copy of this paper.  But it's a method
of using ICMP Timestamp messages to synchronize the clocks of machines
on a local area network to a high degree of accuracy.  Time is always
monotonic on all the machines:  adjustments are done by slowing or
speeding the clocks; never by running them backwards.  Does not address
the problem of how you get the original time, but that can be dealt
with by using a radio clock or getting the original time over a network
from some machine which has one.

Volume-Number: Volume 5, Number 17

From jsq  Sun Jan 12 14:40:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 meeting in Denver and mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Jan 86 20:40:44 GMT
Draft-9:

There is a P1003 meeting this week in Denver, followed by USENIX.
The moderator will be there and not here, so if you don't see
any submissions you send get posted this week, don't get upset:
I will work through any backlog when I return.

Volume-Number: Volume 5, Number 18

From jsq  Sat Jan 18 17:36:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: How does Saudi Arabia handle time zones?
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 18 Jan 86 23:35:59 GMT
Draft-9: TZ

Date: Tue, 14 Jan 86 12:04:40 est
>From: seismo!cbpavo.cbosgd.ATT.UUCP![e-mail] (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

From jsq  Tue Jan 21 11:46:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: ARPA Internet Time Protocols
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 21 Jan 86 17:46:41 GMT
Draft-9: TERM TZ

>A wheel that frequently gets reinvented is how to tell the time over networks.
>Much work has been done on this subject in the ARPA Internet from back when
>there was only the ARPANET up to a few months ago.  This article is a brief
>summary of the existing methods.

I've gotten more than half a dozen requests to post the time RFCs
to mod.sources and no requests not to, so I will do so soon.

Volume-Number: Volume 5, Number 20a

>From jsq  Wed Jan 22 16:25:52 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 22 Jan 86 22:25:10 GMT
Apparently-To: std-unix-archive

[ I don't know if the following suggestion really solves the
problems, but I don't believe anybody has made it before.  -mod ]

From: seismo!philabs!nyit![e-mail] (Rick Ace)
Date: Tue, 21 Jan 86 15:51:31 est

Objections to keeping TZ as a UNIX environment object can be
answered by putting the timezone information (to whatever
degree of precision is necessary) in the per-process context
maintained by UNIX, also called the `u.' area.  The kernel
can offer system calls to query or change the TZ of the
calling process.  Upon fork(), the child inherits its
parent's TZ.

The umask(2) syscall provides a precedent for carrying
special OS-related information in the per-process context
maintained by the kernel.  I'm tempted to propose that TERM
information should be kept there too.
-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY  11568
[phone]

{decvax,seismo}!philabs!nyit!rick

Volume-Number: Volume 5, Number 20b

From jsq  Fri Jan 24 11:13:39 1986
From: jsq (John Quarterman)
>From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 23 Jan 86 18:33:36 GMT
Draft-9: TERM TZ

>From: pyramid!sun![e-mail] (Guy Harris)
Date: Wed, 22 Jan 86 22:02:59 PST

> Objections to keeping TZ as a UNIX environment object can be
> answered by putting the timezone information (to whatever
> degree of precision is necessary) in the per-process context
> maintained by UNIX, also called the `u.' area. ...
>
> The umask(2) syscall provides a precedent for carrying
> special OS-related information in the per-process context
> maintained by the kernel.  I'm tempted to propose that TERM
> information should be kept there too.

This dates back to PWB/UNIX; they wanted to store some per-process
information (namely, the login name, since PWB/UNIX was originally V6-based
and, given a limit of 256 user IDs, required several people to share a user
ID) and they did so in the u-area.  However, when PWB became V7ized, they
stored it - in the environment.

What benefits accrue from storing this information (timezone or terminal
type) in the u-area instead of in the environment?  This proposal implies
that the information isn't protected, since there would be system calls to
change it, so that's not one of the benefits.  (It has been argued that
terminal type information should be stored with the *terminal*, and not with
the process, so it's not clear that the u-area *or* the environment is the
proper place for this.)  The reason the umask was stored in the u-area is
probably so that programs didn't have to change to be affected by the umask;
in order for it to work with "open", it had to be accessible to the kernel,
and the most logical place for variables like that is the u-area.

The main objections I've seen to storing the time zone in the environment
are that it is subject to forgery and that there's no way to set TZ for
*every* process on the system (and even for those processes where you *can*
set it, current S3/S5 requires you to set it independently in several
places).  If the time zone information is moved from the user-mode
per-process data segment to the kernel-mode per-process data segment, this
doesn't solve the problem of forgery unless the system call to set it is
privileged (in which case it isn't really settable by most processes, so why
is it a per-user item?) and doesn't solve the problem of setting it
initially.

The best solution to both of those problems I originally saw in an article
about mixing V7 and S3 compatibility in Xenix.  Microsoft kept the old V7
"ftime" call, which gets the time zone information from the kernel (which is
set at system build time, or if you have something like an EEPROM on your
machine it can be set at boot time; there is no unprivileged system call to
set it, so it's unforgeable), and had "ctime" fetch the time zone
information from the kernel if there was no TZ environment variable.

This solves the problem of setting it initially, as the default setting is
what most programs would want to use; if a user dials in from another time
zone, the program they run as their shell will have to provide some way for
them to set TZ.  It also solves the problem of forgery, assuming the S5
"putenv" function is present.  Have "ctime" (or anybody else) use the
kernel's timezone value if TZ is present but has a null string as a value,
and have programs that want to be guaranteed to get the "official" time zone,
like "uucico", just do 'putenv("TZ=");' and wipe out the supplied time zone.

Volume-Number: Volume 5, Number 21


From jsq  Fri Jan 24 11:19:31 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 24 Jan 86 17:19:09 GMT
Draft-9: TERM TZ

>From: decwrl!mips![e-mail] (John Mashey)
Date: Fri, 24 Jan 86 01:22:08 pst

It was recently suggested here to make TZ & TERM into u_area variables,
with special system calls to tweak them, using umask(2) as precedent.
1) Please don't, at least not without much more thought.
2) Doing umask(2) that way was perhaps a mistake.

Let me shed some light on the history of these things, first recalling
some philosophy that UNIXers are supposed to hold dear:

Nothing goes in the kernel unless it MUST.
Don't add system calls unless you MUST.
Don't add per-process state, unless:
    a) The kernel needs convenient/efficient access to it.
    OR
    b) It must be there for protection.

Way back, PWB/UNIX added 3 per-process data items, which were given
shell variable names.  This was done only after great agonizing.
PWB also changed file creation modes (manually) everywhere to
avoid creating 0666 files; this was not elegant.

It was absolutely clear that it was NOT a good idea to keep adding
piecemeal data items to the u-area to cover every single thing
that people wanted, adding new system calls to get/set each value.
By this time [1977], there were all sorts of (different) extra such
goodies tucked away in different UNIX variants, and this was not good.

Hence, the environment feature was designed into V7 as a general
mechanism to cover all miscellaneous data, such that:
    a) the kernel never needed to access the data items directly.
    b) Users who wanted big environments could pay for them,
    without penalizing everybody by making the u_area qutie large,
    or by having extra storage mechanisms.  Note: when this was
    done, it was noted that there was "the possibility for untasteful
    expansion of the enviroonment", and this has indeed come to pass,
    as one sees multi-KB-size environments floating around.
    c) No extra system calls were needed.
    d) No protection mechanisms were needed or desired [we designed
    a horde of variants that had the environment as a kernel-protected
    list of name-value-protection tuples; every single one of them
    was ugly, expensive, incomprehensible, or a combination.]
    e) System call interface routines could, as needed, interrogate
    environment variables as needed to provide useful behavior;
    these was deemed greatly preferable to having the variable
    knowledge get wired into the kernel.  [example execvp & friends].
    This was especially true when the semantics might want to change,
    as was the case in figuring out how to use $TERM early on.

In some sense, doing umask the way we did was a mistake, since the user
can change it at will, and it could have been implemented via an environment
variable, with appropriate changes to creat.  If I had it to do over,
I'd be strongly tempted to do it this way, although it adds code to
creat(), and the reasonably efficient code wants
to look at the environment once, and cache the initial value.
This has some funny semantics, but could probably be tolerated.
In any case, umask seemed simple enough, and people were, as I recall,
generally thinking that it was tied closely enough to file protection that
it was worthwhile, so it was put in this way.

In summary, I again plead with people to seek solutions that avoid
piecewise additions of u_area state and system calls.  If something
important cannot be done any other way, there is good justification
for doing it.  Otherwise, one is just adding to the overgrowth in there,
rather than helping keep it pruned.

[ I always thought that umask should have been per-directory, not per-process.
In 4.2BSD the group of a new file is that of its parent directory.  If umask
worked similarly, I wouldn't have to be always reminding people to use umask
before working on sources.  -mod ]

Volume-Number: Volume 5, Number 22

From jsq  Tue Jan 28 11:28:03 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 28 Jan 86 17:27:50 GMT
Draft-9: TERM TZ

From: mcnc!duke![e-mail] (Russ Tuck)
Date: Mon, 27 Jan 86 09:18:42 est
Organization: Duke University, Durham NC

I heartily agree that umask should be per-directory rather than per-process.
This is more natural and useful, allowing related files to be given the same
protection automatically as they are created in a directory.

What obstacles are there to putting this behavior in Unix, and to allowing it
in the standard?

                Russ Tuck
                rrt%duke.csnet@csnet-relay
                {ihnp4,decvax,mcnc}!duke!rrt

Volume-Number: Volume 5, Number 23

From jsq  Thu Jan 30 09:38:40 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 30 Jan 86 15:38:10 GMT
Draft-9: TERM TZ

>From: floyd!opus![e-mail] (Kenneth Almquist)
Date: Tue, 28 Jan 86 21:46:36 EST
Organization: Bell Labs, Holmdel, NJ

This article proposes a method of handling time zones which I think
meets all the requirements that have been mentioned.

The offset from GMT of some timezones is not an integral number of
hours, so I specify this offset in seconds.  The idea of compiling a
complete list of time zone names into ctime is utopian, so I have
included the time zone name.  Finally, the only way to deal with
daylight savings time appears to be to specify a list of time inter-
vals during which it applies.  Putting this all together, we get the
following, which should be placed in /usr/include/tz.h:

#define TZNAMLEN 6
#define NTZLIM 30

struct tzlimits {
    time_t tzl_start;        /* when daylight savings time starts */
    time_t tzl_end;            /* when it ends */
};

struct tz {
    time_t tz_offset;        /* offset in seconds from GMT */
    char tz_name[TZNAMLEN];        /* regular name of this time zone */
    char tz_dstname[TZNAMLEN];    /* name during daylight savings time */
    struct tzlimits tz_dst[NTZLIM];    /* intervals when DST applies */]
};

extern struct tz tz;

/* end of tz.h */


It should be possible for a user to use a time zone other than the
system time zone, but on the other hand it should be possible for
programs like uucico to be able to use the system time zone regardless
of what the user does.  Ctime should not break just because the
environment has been zapped.  To meet these requirements I propose the
routine "gettz".

Gettz is invoked as "Gettz(flag)".  The first call to gettz fills in
the global variable tz.  Subsequent calls to gettz have no effect.

Normally gettz gets the local time for the machine, but if flag is
nonzero and the environment variable TZFILE is set, gettz reads the
contents of that file specifed by TZFILE into the variable tz instead.

The routines ctime and localtime call gettz with an argument of 1, so
that programs normally do not need to invoke gettz directly.
Programs like uucico which want to force the system time zone to be
used should call gettz with an argument of zero prior to the first
call of localtime or ctime.

Gettz returns a negative value when an error occurs and zero
otherwize.  When an error occurs, gettz will attempt to set tz to the
local time zone; if that fails it will set it to GMT.

For the benefit of users, the directory /usr/lib/tz contains files
specifying all the common timezones.  The user can also create his own
private timezone files using the utility maketz.  (These files cannot
be created with text editors because they are binary files.)  The
local time zone is linked to /usr/lib/tz/local.  Most versions of the
operating system will copy this file into the kernel at system boot
time and provide a system call to fetch the local time zone which will
be used by gettz, but this is not required.  (The last sentence is for
the benefit of very small machines that might find storing the time
zone in the kernel to be too costly; I may be worrying too much here.)

Any problems with this?  The main one is that distant times will not
be represented in daylight savings time; I don't think that this is a
problem because times before Jan 1, 1970 cannot be represented anyway,
and it is a matter for speculation what the daylight savings time rule
will be in the year 2000.
                Kenneth Almquist
                ihnp4!houxm!hropus!ka    (official name)
                ihnp4!opus!ka        (shorter path)

Volume-Number: Volume 5, Number 24

From jsq  Fri Jan 31 14:06:58 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: umask per directory?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Mark Brader)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Summary: No.
Date: 31 Jan 86 20:06:44 GMT
Draft-9: 5.1 5.3.3

Date: Fri, 31 Jan 86 13:19:46 cst
>From: ihnp4!utzoo!lsuc!msb (Mark Brader)
Organization: Law Society of Upper Canada, Toronto

> From: mcnc!duke![e-mail] (Russ Tuck)
> Subject: Re: TZ and TERM per process
(May I remind the moderator to watch out for inappropriate Subjects?)
[ You're right:  I missed that one.  -mod ]

> I heartily agree that umask should be per-directory rather than per-process.
> This is more natural and useful, allowing related files to be given the same
> protection automatically as they are created in a directory.

And I heartily DISAGREE.  My umask is 022, and when I create a file
whose mode is not 644 or 755, it is a rare and earthshaking event.
Seems to me that if I was a secretive umask 077 type, or a permissive
umask 0 type, I'd feel exactly the same way.  Directories with booby
traps are the mark of VMS, not UNIX.

[ The moderator reminds the posters that attacks on ideas as being
appropriate to a given operating system don't add much to the discussion.
Furthermore, if you set the umask on your home directory to 022,
and that were inherited through your directory subtree, you would
get the same effect for your files as with a per-process umask.

I'd be really interested in any comments from John Mashey as
to what arguments arose concerning this idea when the per-process
umask was decided upon.  -mod ]

         { decvax | ihnp4 | watmath | ... } !utzoo!lsuc!msb
            also via { hplabs | amd | ... } !pesnta!lsuc!msb
Mark Brader        and           uw-beaver!utcsri!lsuc!msb

Volume-Number: Volume 5, Number 25

From jsq  Sat Feb  1 18:21:08 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 2 Feb 86 00:20:37 GMT
Draft-9: TERM TZ

Date:    Fri, 31 Jan 86 22:48:27 PST
From: UCLA Computer Club <[e-mail]>

But with this proposal, what about the past timezone changes? The DST rules
have changed in the past. As it is, this routine will never say a past time
was DST.
            Michael Gersten
--
disclaimer | From out on the disk there arose such a platter | Michael Gersten

Volume-Number: Volume 5, Number 26

From jsq  Sat Feb  1 18:24:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 2 Feb 86 00:23:34 GMT
Draft-9: TERM TZ

>From: ihnp4!mecc!sewilco (Scot E. Wilcoxon)
Date: Sat Feb  1 15:52:38 1986

U.S. Congress is concerned about election projections affecting
the results of some elections.  One of the people working on
legislation to close polls at the same time across the
nation was being interviews on NPR this week.

Because of the four-hour time zone difference across the continent,
the current proposal includes extending Daylight Savings Time
only in the west and only during (Presidential?) election years.

This proposal highlights the need for a very flexible time algorithm.
Before this, I certainly hadn't thought of election year as a
factor to consider.

(Observations about computerized forecasting affecting computerized
time probably belong in another group.)
--

Scot E. Wilcoxon  Minn. Ed. Comp. Corp.            quest!mecc!sewilco
45 03 N / 93 15 W   [phone] {ihnp4,mgnetp}!dicomed!mecc!sewilco

Volume-Number: Volume 5, Number 27

From jsq  Mon Feb  3 10:30:22 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 16:29:59 GMT
Draft-9: TERM TZ

>From: pyramid!pyrcorp!ncr-sd!greg
Date: Sat, 1 Feb 86 22:45:20 pst
Subject: Re: TZ and TERM per process
Organization: NCR Corporation, Rancho Bernardo

>>From: floyd!opus![e-mail] (Kenneth Almquist)
>Date: Tue, 28 Jan 86 21:46:36 EST
>Organization: Bell Labs, Holmdel, NJ
>
>This article proposes a method of handling time zones which I think
>meets all the requirements that have been mentioned.
>
> [ a scheme where timezone information is kept in a binary table
>   and read in upon demand.  Also includes a clever technique for
>   allowing users to use non-local timezones while permiting system
>   programs to still run in local time. ]
>
>Any problems with this?

An interesting idea; I'd like to see it explored further.  The impact
would not seem to be great, there are minimal changes to existing code,
it allows flexibility in the choice of timezone, and it has a system-wide
default that isn't compiled in.

There's one change I would suggest: the offset for each daylight savings
time should be specified independently; sometimes the clock shift is
not exactly one hour -- there are some areas with double daylight
savings (two hours different), for example.  The name of the zone may
have to be specified, as well.  Perhaps a better way would be to have
some entries that compactly represent the usual case (one hour offset,
standard name) and then have some provision for non-standard offsets
and names.
--
-- Greg Noel, NCR Rancho Bernardo    [e-mail] or [e-mail]

Volume-Number: Volume 5, Number 28

From jsq  Mon Feb  3 11:57:41 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per dir
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 17:57:20 GMT
Draft-9: 5.1 5.3.3

>From seismo!gatech!astrovax!fisher!djl Mon Feb  3 11:28:40 1986
Date: Mon, 3 Feb 86 02:00:12 est

As a big fan of least common denominator, rather than feeping creaturism,
I would note that it is quite easy to get umask/dir, by simply using
the facilities provided by your shell.  For instance, using csh,
alias cd to do 'source .exitdir; cd \!* ; source .enterdir' , and
use the shell scripts called .enterdir and .exitdir to do directory
specific initializations.

            ***dan

[ Since I'm taking sides on this, I'm going to post my comments
as a followup by jsq instead of notes by the moderator.  -mod ]

{allegra,astrovax,princeton}!fisher!djl
The misplaced (That car sure is rusty!) Californian

Volume-Number: Volume 5, Number 29

From jsq  Mon Feb  3 12:38:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per dir
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 18:07:35 GMT
Draft-9: 5.1 5.3.3

>From: [e-mail] (John Quarterman)
Date: Mon, 3 Feb 1986 12:00:13 CST

> As a big fan of least common denominator, rather than feeping creaturism,
> I would note that it is quite easy to get umask/dir, by simply using
> the facilities provided by your shell.  For instance, using csh,
> alias cd to do 'source .exitdir; cd \!* ; source .enterdir' , and
> use the shell scripts called .enterdir and .exitdir to do directory
> specific initializations.
>
>             ***dan

To set up a source tree so that everybody used the same umask on it
with your method would require everybody to change their .cshrc.
To do it with real umask per directory would require only setting
the umask for the directory.  The latter looks more like the least
common denominator to me.

The more interesting question is *how* do you set a umask on a
directory?  Do you try to derive the bits from the directory mode
bits in some way, such as setgid means apply the group mode bits
as the mask?  Or do you have to have an extra word in the inode?
Or do you do it by a file in the directory?  And how do you get
the umask inherited by child directories?

I would think the preferred approach would be to somehow derive
the umask from the directory mode bits.  Inheriting could be done
by just setting the umask for all the subdirectories with find.
Except that mkdir should likely make sure the umask were inherited.

One wonders if most of the people for umask per directory are using
4.2BSD or 4.3BSD and those against are using other systems.
The desirability becomes obvious after you get used to the 4.2BSD
method of assigning the group of a new file according to the group
of its parent directory.

Volume-Number: Volume 5, Number 30

From jsq  Mon Feb  3 15:10:38 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process (really environments and setuid scripts)
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 21:10:14 GMT
Draft-9: TERM TZ

From: harvard!mit-eddie!frog!rfm (Bob Mabee)
Date: Sun, 2 Feb 86 20:56:51 est
Organization: Charles River Data Systems, Framingham MA

Several posters have mentioned that a setuid program or shell script can be
compromised by suitably altering the environment list.  This is a nasty
problem because tools (the shell, library functions) are likely to develop
new dependencies on the environment as new functionality is added, and we
are not likely to think of all the possible attacks.

I suggest that the kernel should close this hole once and for all, by clearing
the environment at the point in exec() where it implements the SETUID mode.

Some programs operate incorrectly when invoked from single-user mode, or the
startup scripts, or cron, because the environment is deficient.  For example,
the time zone is likely to revert to EST.  This change forces at least the
SETUID programs to be tested (implies debugged) under such conditions.
Obviously, the time zone should default to something inappropriate for the
development site, so you notice during testing.

Instead of clearing the environment, exec() could substitute a canonical
administrative environment, from a kernel holding area or from a file.
Note that exec() is in a good position to fetch arbitrary files - it uses
high-level kernel facilities just like a user program.

                Bob Mabee @ Charles River Data Systems
                decvax!frog!rfm

Volume-Number: Volume 5, Number 31

From jsq  Mon Feb  3 15:16:02 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 21:15:35 GMT
Draft-9: 5.1 5.3.3

Date: 2 Feb 86 21:02:09 EST (Sun)
>From: floyd!opus![e-mail] ()
Organization: Bell Labs, Holmdel, NJ

I agree with Mark Brader.  In response to the moderator's suggestion
that "if you set the umask on your home directory to 022, and that were
inherited through your directory subtree, you would get the same effect
for your files as with a per-process umask," I would point out that
this doesn't work for files in /tmp.

[ Good point.  Assume the old per-process umask still exists as a default,
though.  (I've been assuming that but haven't mentioned it.)  If /tmp
has no directory umask, things work.  Most of the other objections
are also accounted for.  -mod ]

My major objection, though, is that the proposal would break existing
programs.  For example, tar and cpio would have to be modified to
handle the per-directory umask.  This would mean new tar and cpio tape
formats, which would probably be unreadable by existing versions of tar
and cpio.  I wrote a version of rcp a couple of months ago which would
have to be changed.  Programs as unlikely as ed and passwd would
require modification.

In my view, the benefits of going to per-directory umasks are
outweighed by the disadvantages.  I might be convinced otherwise with
additional argument.  But changes which are not backwards compatible
must be justified by *major* benefits.
                Kenneth Almquist
                ihnp4!houxm!hropus!ka    (official name)
                ihnp4!opus!ka        (shorter path)

Volume-Number: Volume 5, Number 32

From jsq  Mon Feb  3 15:32:12 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: umasks and P1003 in general
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 3 Feb 86 21:31:52 GMT
Draft-9: 1.0 5.1 5.3.3

[ Comments within square brackets like this are by the poster,
unless they end with -mod, when they are by the moderator.  -mod ]

Date: Sun, 2 Feb 86 14:29:57 pst
>From: [e-mail] (Armando P. Stettner)

Hi.
On the subject of umasks:
I feel that setting the modes of a created file according to a
per-directory umask is a bad idea.

On the surface, it seems like it might be a good idea.  But what this
change does is to remove some of the responsibility and choice of the
program and certain choices of the invoker to place it where such
decisions may have been (perhaps) arbitrarily made by the people who
created and/or own the target directory.  The word `arbitrary' may be
too strong a word but the point I am trying to make is that one
important characteristic of UNIX I have come to respect, appreciate,
and love is that UNIX doesn't do things one doesn't ask it to do nor
does it change or coerce things one produces (files on UNIX vs files on
VMS, as an example of the latter).  Please leave the decisions with the
programmers and the users.

[ The same argument would apply just as well to existing directory
protection modes or the 4.2BSD method of assigning groups to files.
However, the moderator has been sticking his oar in too often lately
and will try to be quiet.  -mod ]

My second objection stems from the thought that it might break a large
set of existing programs (uucp, tip, lp{r,d,rm}, data base subsystems
that run across several UNIX implementations and can not assume certain
record locking facilities, etc).  [Don't nickel and dime me with
implementation details; try and understand what I am trying to say.  I
could check the sources also.  Thanks.]

[ Please elaborate.  -mod ]

On the UNIX IEEE P1003 effort, in general:
This brings me to my next (and maybe the more important) point:  I have
been watching this news group and the standards efforts in general (the
ANSI C effort to a lessor degree).  I am concerned by what I see.  I am
afraid what is happening is sort of what people feared would happen if
a Constitutional Convention were to take place and this is: people now
have a chance to change things.  Intentions are all well and good (I
assume this).  However, things are getting changed.  What I would like
to see in a standard that is attempting to pull together a fragmented
world, such as the UNIX world, is a strong subset of the
characteristics and functions in the more common (popular?) existing
implementations; not one which is implemented by no current version.  I
don't know; maybe this is what is wanted by people on the IEEE
committee:  no current vendor has a head start ...

There are few good things that are done by ``committee'' that I know
of.  This does not mean that I feel that P1003 should be disbanded;
however, I feel the members should be aware of the possible pitfalls of
`by committee' design and work to avoid them.

[ I'm overdue for posting a report on the latest P1003 meeting and will
address this subject.  However, be aware that the newsgroup is not P1003,
and that the committee members constantly raise your concern.  -mod ]


Maybe the resulting work of P1003 should be called UNIX2 or unUNIX
(Onionix?**).

[Needless to say (I know: then why say it?), these opinions are mine
and not necessarily DEC's]

    Armando Stettner
    decwrl!aps, decvax!aps, decwse::aps, aps@berkeley


** Onionix is a trademark of aps enterprises...

Volume-Number: Volume 5, Number 33

From jsq  Tue Feb  4 15:12:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: per directory umask
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Feb 86 21:12:33 GMT
Draft-9: 5.3.3

Date: Tue, 4 Feb 86 07:19:30 PST
>From: mordor!lll-crg!hoptoad!laura (Laura Creighton)

I think that while it might have been better if umask had worked this way from
the beginning, changing existing behaviour is a bad idea.  You will burn
people who expect one behaviour and get another.

I am actually not sure that it is a good idea at all.  The main reason I know
of that people want the proposal is so that they can have a varying levels of
protection and privacy without much effort.  But if they really want privacy,
then they *should* be going to the effort -- this is the whole idea.  If they
depend on the filesystem when they should be depending on themselves they are
going to get a rude surprise one day when their security is compromised.

I don't think that the current umask situation is broken.  Why are we trying
to fix it?

[ See the following article by Dan Franklin.  -mod ]

Laura Creighton
ihnp4!hoptoad!laura
hoptoad![e-mail]

Volume-Number: Volume 5, Number 34

From jsq  Tue Feb  4 15:16:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per dir
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Feb 86 21:16:28 GMT
Draft-9: 5.1 5.3.3

Date:     Tue, 4 Feb 86 11:04:50 EST
>From: Dan Franklin <[e-mail]>

I have always felt that the UNIX umask "solution" to the problem of protection
was inadequate.  If I had per-directory protections, then my personal hierarchy
would be writable only by me (644), except for my mail files which would be
even more private (600).  The source hierarchy I share with others on my
project would be read-write by the group (664).  Since all we have is umask, I
can't do this.  I must set umask to 002 so that when I work on the group source
hierarchy, others can modify my modifications.  I put up with the lessened
security in other areas because most programs implement various ad-hoc
solutions--the mail system creates all its files 600, etc.  It's not perfect;
when I use a filter on a message file in one of my MH folders, the output file
is created group-read-write.  But it mostly works.

The cd alias is a clever suggestion, but like umask, it only mostly works.
Your shell, and the shells of all the other users you ever expect to create
files in those directories, must have aliases (thus leaving out users of the
BSD Bourne shell and the System V.1 shell) and it doesn't work with commands
like "find," which can recurse over a hierarchy and create files (via -exec)
without ever forking a shell of any kind.  Some daemons don't exec shells,
or only exec the Bourne shell (/etc/rc, for instance).

However, just because umask is inadequate doesn't mean this committee should
try to fix the problem.  This inadequacy is not widely enough recognized to
justify creating a brand-new scheme in a standards document without testing it.
Also, the standard would (I think) have to retain umask in its current form;
and having two ways to do the same thing is always unfortunate.  Other
submitters have also raised good points about compatibility (tar and cpio).  So
much as I like the idea, I think it has to be left for innovators to try
adding, not for a standard.

[ No one has proposed changing umask in a standards document.  -mod ]

    Dan

Volume-Number: Volume 5, Number 35

From jsq  Tue Feb  4 16:08:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix and P1003
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 4 Feb 86 22:08:03 GMT
Draft-9: mod.std.unix

There seems to be widespread confusion as to the relation of the
newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the
IEEE P1003 standards committee.  Allow me to try to clear some of it up.


Because something is discussed in mod.std.unix does not mean that
it is automatically proposed to P1003 for inclusion in the standard.
Proposals to the committee have to be more formal.  Especially they
have to include specific proposed wording.

As it happens, the moderator of the newsgroup is also the USENIX
representative to the committee.  As such, I am willing to present
proposals to the committee if someone actually has some to present.
However, the proposer has to specifically request that for a specific
proposal and I have to agree to it before it will happen.

It is true that several committee members follow the newsgroup and
that I make sure that copies of articles from the newsgroup go to
appropriate technical reviewers or are mentioned to the committee
as a whole.  However, they are not presented as proposals:  they
are presented as comments.  They may help committee members understand
the context of a topic which is treated in the standards document,
but they are unlikely to cause new topics to be added to the document.

This is not to say that input from the newsgroup is not useful
to the committee.  A number of problems with the latest drafts
were pointed out in the newsgroup and fixed because of that.
The time zone discussion has brought up some points which will
probably affect the eventual treatment of that subject by the
committee.


Because something is discussed in mod.std.unix does not even
necessarily mean that it has anything to do with the P1003 committee.
The directory umask discussion is an example.  No one has proposed
that the committee incorporate such a facility, and I would be
surprised if anyone did.  There were three main reasons I originally
brought the subject up:
    I've never heard any convincing arguments for why it was not
        done that way in the first place;
    Somebody might think of a way to implement it which avoided
        the tar and rcp type problems; and
    There has been so little traffic in the newsgroup lately that
        a slightly controversial subject seemed indicated.


The committee is very aware that they should not be introducing
new facilities.  It has happened a few times.  The only one
I can think of at the moment is file locking, specifically the
mandatory locking feature of flock (which was actually introduced
by the /usr/group committee).  This is also, not coincidentally,
one of the most controversial things in the current document
(at the moment it's in an appendix), even though its proponents
only back it because they are convinced it is necessary.

You will find things in the draft standard document which do not
correspond to your local system, regardless of what your local system
is.  This is because in the real world there are at least two major
variants of UNIX and many minor ones.  To pick one and standardize on
it alone would be to try to outlaw all the others.  This is probably
not even possible, even if it were desirable.  The committee has chosen
instead to try to produce something which is not exactly like anything
out there but which can be implemented with relatively minor changes on
most existing systems.

I will post a report on the latest committee meeting soon in which
I will try to sketch how the committee actually works.

Ritual disclaimer:  this article is constructed of my personal opinions
and does not necessarily represent any official position of IEEE, P1003,
USENIX, /usr/group, or any other organization.

Volume-Number: Volume 5, Number 36

From jsq  Tue Feb  4 21:31:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 5 Feb 86 03:31:02 GMT
Draft-9: 5.1 5.3.3

Date: Sun, 2 Feb 86 23:48:32 pst
>From: ihnp4!decwrl!mips!mash (John Mashey)

1] I don't believe the idea of associating uname values to directories
was ever discussed, as far as I can remember.  The whole thing really
came about because PWB/USG believed that security had to be tightened,
and Research and some others wanted to continue to run conveniennt loose
systems.  It was believed that setting a default per systems was fine,
but needed to be overridden as needed, so it it was put in to be inherited
in the same way as most other thigns, i.e., by process tree inheritance.

2] I doubt whether the idea would have been considered seriously if
it had been brought up, at least if umask were the only reason for
adding the mechanism.  Why?
a) Remember that UNIX was designed by people who'd been working on
MULTICS, whose directories include considerable more protection
information.
b) However, UNIX directories are ONLY names.  There is no
system-implied state (except for the current directory itself)
implied by the current directory.  Nothing else is inherited or
modified by one's position in the file system.
c) I can't remember the reference, but I'd swear that one of the
early papers said that b) was on-purpose.
d) This doesn't mean the idea is necesarily bad, merely that I doubt
anybody would have believed that it fit with UNIX.

3] [PHILOSOPHICAL HARANGUE]: kernel mechanisms should be added only
when really justified by serious need.  In particular, one should
try to make new mechanisms be general enough to cover numerous
special cases, not add special cases one by one.  In this case,
good questions to ask are:
    Is there per-process state information [either in the u-area
    or returned by doing a chdir(2)] that should be changed
    automatically when doing a chdir?  If so, can one store this
    in a file in the directory?  Are pieces of state added, deleted,
    merged, inherited, etc?
If one can come up with a few examples, then perhaps the general
mechanism could be designed.  One could easily experiment with
this: for example, the chdir function call might be augmented
in any of many ways. It would be much more enlightening to hear
a proposal for a general mechanism, backed up by multiple examples &
illustrations of existing attempts within the systems to achieve the
effects.  [END PHILOSOPHICAL HARANGUE]

[ Now *that* was an article!  But I don't understand what chdir
has to do with it:  the idea is to create a new file according to
the umask of its parent directory, not of the current directory.
I.e., "cat this > there/that" should create "that" in the same
modes according to the umask of "there" regardless of what "." is.
-mod ]

Volume-Number: Volume 5, Number 37

From jsq  Thu Feb  6 06:57:19 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: "Charles J. Antonelli" <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Feb 86 12:57:07 GMT
Draft-9: 5.1 5.3.3

Date: Tue, 4 Feb 86 14:05:09 est
>From: "Charles J. Antonelli" <[e-mail]>
Summary: Use an appropriate alias for `cd' [ Nope. -mod ]
Organization: University of Michigan EECS Dept.

I obtained the following idea from a colleague.  It can be used with csh
to achieve the desired effect.  Define the following alias:

alias cd 'if (-o .exit ) source .exit; chdir \!*; if (-o .enter ) source .enter'

Then create .enter and .exit files within the directories whose umasks
are to be controlled; the files contain the appropriate umask commands along
with anything else you wish to do whenever a directory is entered or exited.
In my case the new umask is echoed for verification.

The .exit file is useful mainly in those cases where only a small subset
of the directories have .enter files; if every directory has one then
.exit is not strictly necessary.

The alias checks for ownership to prevent possible corruption.

Charles J. Antonelli        Phone:  [phone]
The University of Michigan    Csnet:  [e-mail]
1508 East Engineering        Usenet: [e-mail]
Ann Arbor, MI   48109            ihnp4!umich!cja

[ This is one of several such shell initialization schemes I've
received (and the only one I'm going to post).  They all miss the
point:  a new file should be created according to the modes of its
*parent* directory, not the creating process's *current* directory.
That is, "cat this > there/that" should create "that" with the same
modes regardless of where "." is.  (If "there" has the directory umask
feature enabled.)  -mod ]

Volume-Number: Volume 5, Number 38

From jsq  Thu Feb  6 07:01:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Feb 86 13:01:32 GMT
Draft-9: 3.1.2 4.2

Date: Wed, 5 Feb 86 08:12:33 pst
>From: seismo!sun!rtech!daveb (Dave Brower)
Organization: Relational Technology Inc, Alameda CA

At first glance I thought clearing the environment on the exec of a setuid
program might be OK, but it seems full of awkward side effects.

For instance, I could not have one of my favorite programs, nasty, that
runs setuid root and then execs the remainder of its arguments with
a negative nice value.  The real child process would never be able to
get a reasonable environment.

The answer is only to do limited operations when in setuid.  The best
way to do this would be to allow processes to painlessly shift back and
forth between their real-uid and effective-uid.  This is allowed, but
not documented on BSD, but appears not to be allowed at all on SV.
This way, you can have your one section that need to run setuid be setuid
whenver needed, while running as the real user the reset of the time.

Lastly, you really need to be able to set fixed priorities rather than
just nice values so things like a memory/cpu pig server process can avoid
getting bumped.  Convex did this by making nice values < -20 and > +20
be a fixed priority.  This seems quite reasonable, and lets a 'nasty'
root program set the fixed high priority.

-dB

Volume-Number: Volume 5, Number 39

From jsq  Thu Feb  6 07:08:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Feb 86 13:08:27 GMT
Draft-9: 5.1 5.3.3

Date: Wed, 5 Feb 86 17:43:47 est
>From: seismo!harvard!think!mit-eddie!jbs (Jeff Siegal)

No one is suggesting "fixing" umask, only adding new capabilities
for those who will choose to use it.  I personally think that
allowing people to choose the way they want to do things, rather
than trying to second-guess what will be best.

Volume-Number: Volume 5, Number 40

From jsq  Thu Feb  6 07:16:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per dir
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Alexander Dupuy)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Feb 86 13:15:56 GMT
Draft-9: 5.1 5.3.3

Date: Thu, 6 Feb 86 06:06:25 EST
>From: Alex Dupuy <[e-mail]>

Organization: Columbia University

In <[e-mail]> [e-mail] (John Quarterman) writes:
>
> The more interesting question is *how* do you set a umask on a directory?  Do
> you try to derive the bits from the directory mode bits in some way? ...  And
> how do you get the umask inherited by child directories?
>
> I would think the preferred approach would be to somehow derive the umask
> from the directory mode bits.  Inheriting could be done by just setting the
> umask for all the subdirectories with find.  Except that mkdir should likely
> make sure the umask were inherited.

Having primarily used bsd Unix for a few years, and before that, Twenex, which
has default file protections on a per-directory basis, I would agree that
keeping the protection masks in the directory tree is better than the Unix's
umask.  Still, as some have pointed out, for reasons of compatibility with tar
and cpio, adding information to the directory structures would be a mistake.
Also, switching over to a purely directory based umask would cause security
problems with existing programs expecting umask to work properly.

A directory/process based umask scheme which provides compatibility with the
normal Unix filesystems, and allows naive programs to operate securely (when
opening files in /tmp or /usr/tmp, say) is still possible, and would provide a
more flexible mechanism than the common directory based systems.  It might
work like this:

  The setuid and setgid bits in the mode of a directory would be used to
  specify which logical combination of umask and directory mode access bits
  should be used as the mask when creating files or directories.  The logical
  combinations would be

    00 mask = umask
    01 mask = umask | ~directory mode
    10 mask = umask & ~directory mode
    11 mask = ~directory mode

Users would set their umasks much as they do now, to cover the default case.
Directories like /tmp would be set 00 for security compatibility, while mail
directories would be set 01 for greater protection, project directories would
be set 10 to ensure that files and subdirectories were group writable, and
home directories might be set 11.

For the benefit of really paranoid programs/users, two bits could be added to
the umask to override the directory combination bits, although doing so would
add to the complexity of the system without really increasing security or
flexibility.


@alex

Volume-Number: Volume 5, Number 41

From jsq  Fri Feb  7 09:14:46 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>, <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 7 Feb 86 15:14:32 GMT
Draft-9: 5.1 5.3.3

Date: Fri, 7 Feb 86 01:12:07 pst
>From: pyramid!decwrl!mips!mash (John Mashey)

Re: having followed this discussion somewhat randomly, I thought that
was one the ways that people were casting this, and so cast the example
that way.  Perhaps a better way to state the general case is:
    a) one needs to specify the state vector associated with each
    object in the system.
    b) One must specify how operations depend on the state of the objects.
    c) Any time one adds a new item to an existing state vector,
    one should carefully check to see that it is needed, and is as general
    as makes sense, not just a special case.
    d) ANy time one adds an enitre new state vector, or a completely
    new kind of interaction with operations, like c), but more so.

Certainly, I don't feel very strongly about any of this, EXCEPT that
this feels to me like a wart of the following nature:
    a) It is a special case of potential value.
    b) It is a special case of some general case that has not yet been
    expressed.
    c) It is not of such critical nature that it should be implemented
    without better understanding the general case.
    d) If somebody really wants to, they can get almost any of
    the proposed effects by using 1) tweeked creat(2) Interface routine,

    2) environ variable checked by the new creat()
    3) a dot-file with umask value left in each directory.
The questions is: does anybody who has the source to do this have enough
interest to try this out?

Volume-Number: Volume 5, Number 42

From jsq  Sat Feb  8 02:19:05 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 8 Feb 86 08:18:25 GMT
Draft-9: 3.1.2 4.2

>From: seismo!gatech!akgua!pegasus!hansen (Tony Hansen)
Sat Feb  8 00:48:16 1986
Date: Sat, 8 Feb 86 00:31:29 EST
Organization: AT&T-IS Labs, Lincroft, NJ

< The answer is only to do limited operations when in setuid.  The best
< way to do this would be to allow processes to painlessly shift back and
< forth between their real-uid and effective-uid.  This is allowed, but
< not documented on BSD, but appears not to be allowed at all on SV.

System Vr2 allows a non-root setuid process to call setuid(2) with either
the real uid or the saved effective uid, allowing the process to painlessly
switch back and forth. This change occurred between System V and Vr2.

One slight difference is that Vr2 non-root setuid(2) sets the effective uid
and not the real uid. Only a root setuid(2) will change the real uid as
well; which can't then be changed back.

                    Tony Hansen
                    ihnp4!pegasus!hansen



Volume-Number: Volume 5, Number 43

From jsq  Tue Feb 11 10:09:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Feb 86 16:09:24 GMT
Draft-9: 3.1.2 4.2

>From: Kay Dekker <seismo!mcvax!warwick!kay>
To: ut-sally!std-unix
Organization: Computer Science, Warwick University, UK
Date: Sat,  8 Feb 86 10:20:38 GMT

>Date: Wed, 5 Feb 86 08:12:33 pst
>>From: seismo!sun!rtech!daveb (Dave Brower)
>Organization: Relational Technology Inc, Alameda CA
>
>The answer is only to do limited operations when in setuid.  The best
>way to do this would be to allow processes to painlessly shift back and
>forth between their real-uid and effective-uid.  This is allowed, but
>not documented on BSD, but appears not to be allowed at all on SV.
>This way, you can have your one section that need to run setuid be setuid
>whenver needed, while running as the real user the reset of the time.

This is *exactly* what I found myself needing to do last night...  When
you say "BSD", does this include 4.1?  If so, how do I do it?  and why
isn't it documented?

                        Kay.
--
Virtue is its own punishment.
            ... mcvax!ukc!warwick!kay

[ It was introduced in 4.2BSD.  Here's the man page.
Note that only super-user can actually switch back and forth
between ruid and euid.  -mod ]


SETREUID(2)         UNIX Programmer's Manual          SETREUID(2)

NAME
     setreuid - set real and effective user ID's

SYNOPSIS
     setreuid(ruid, euid)
     int ruid, euid;

DESCRIPTION
     The real and effective user ID's of the current process are
     set according to the arguments.  If _r_u_i_d or _e_u_i_d is -1, the
     current uid is filled in by the system.  Only the super-user
     may modify the real uid of a process.  Users other than the
     super-user may change the effective uid of a process only to
     the real uid.

RETURN VALUE
     Upon successful completion, a value of 0 is returned.  Oth-
     erwise, a value of -1 is returned and _e_r_r_n_o is set to indi-
     cate the error.

ERRORS
     [EPERM]        The current process is not the super-user and
                    a change other than changing the effective
                    user-id to the real user-id was specified.

SEE ALSO
     getuid(2), setregid(2), setuid(3)

Printed 2/11/86         12 February 1983                        1

Volume-Number: Volume 5, Number 44

From jsq  Tue Feb 11 10:16:24 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Feb 86 16:15:56 GMT
Draft-9: 3.1.2 4.2

Date: Sun, 9 Feb 86 22:00:20 pst
>From: pyramid!csg (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA

>> The answer is only to do limited operations when in setuid.  The best
>> way to do this would be to allow processes to painlessly shift back and
>> forth between their real-uid and effective-uid.  This is allowed, but
>> not documented on BSD, but appears not to be allowed at all on SV.
>
>System Vr2 allows a non-root setuid process to call setuid(2) with either
>the real uid or the saved effective uid, allowing the process to painlessly
>switch back and forth. This change occurred between System V and Vr2.

Something is silly here; if you think it's important I'd appreciate it if
you'd verify this with someone who knows:

System V has always had the ability to switch the effective UID between the
real UID and the saved effective UID. (And it isn't documented, BTW. We
discovered it the hard way when some of the V.0 utilities wouldn't run.)
Berkeley, however, has never had this capability. There are a number of other
curious variations and exceptions, although that's fodder for net.unix... :-)

[ Does anybody know when the capability was introduced?  PWB, System III,
System V?  As for what BSD has along these lines, see previous article.

I'm beginning to agree that this discussion really belongs on net.unix.
-mod ]

<csg>

Volume-Number: Volume 5, Number 45

From jsq  Tue Feb 11 10:20:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Spencer W. Thomas)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 11 Feb 86 16:20:24 GMT
Draft-9: 3.1.2 4.2

Date: Mon, 10 Feb 86 11:06:44 MST
>From: [e-mail] (Spencer W. Thomas)
Organization: University of Utah, Salt Lake City

In article <[e-mail]> pegasus!hansen (Tony Hansen) writes:
>One slight difference is that Vr2 non-root setuid(2) sets the effective uid
>and not the real uid. Only a root setuid(2) will change the real uid as
>well; which can't then be changed back.

This seems to me to be a potential security problem.  It means that you
cannot write a program to give a certain set of people access to a
particular uid (ala su) without making it setuid root.  It would be much
safer, it seems to me, to make it setuid to the uid you want to give
access to, and let it do setuid(geteuid()).  This is necessary if, for
example, the program wants to fork a real setuid program with the new
uid.  We have a number of programs that do this.  Yet another reason to
not use SV.

[ Please, let's not start up the System V vs. 4BSD argument here.  -mod ]

--
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, [e-mail])

Volume-Number: Volume 5, Number 46

From jsq  Tue Feb 11 22:08:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Feb 86 04:07:42 GMT
Draft-9: TZ.P.046

>From: seismo!hao!asgb!benish!devine
Date: Tue, 11 Feb 86 11:21:51 mst

  Hi, here is a letter that I sent to the IEEE mailing address for
POSE proposals.  It deals with timezones and Daylight Saving Time
rules and how to incorporate them portably into a UNIX environment.
Its advantages are: follows System III/V model; allows users and
programs to override system timezone information; works for all
present country TZ and DST rules; and flexibility.

Bob Devine; 3133 Lake Park Way; Longmont, CO 80501; [phone]
(seismo!hao!asgb!devine  sdcrdcf!bmcg!asgb!devine)

---------------------------------------------------------------------

    Secretary, IEEE Standards Board
    Institute of Electrical and Electronics Engineers
    345 East 17th Street
    New York, NY 10017




      This is a suggested resolution for the handling of world timezones
    and Daylight Saving Time for the P1003/Portable Operating System
    Environment document.  Appendix A.3 asked for such a resolution.


      The major points of the proposal are:


            1. There is a world-readable, superuser-modifiable file
               named "/etc/TIMEZONE" that describes the per-system
               timezone information and Daylight Saving Time rules.


            2. TIMEZONE contains the following lines in Bourne shell
               syntax:

               TZ=ABC
               DST="dst1 dst2"
               export TZ DST


            3. The TZ variable has 2 required parts (and an optional 3rd):

               A = standard abbreviation for the timezone as used by the
               local area
                   A :== [A-Z][A-Z]*
               B = plus or minus difference in minutes from Universal Time,
               plus for those locations east of GMT, minus for west
                   B :== [+-][0-9][0-9][0-9]
               C = standard abbreviation for the timezone as used by the
               local area when Daylight Saving Time is in effect.  This
           part of TZ may be absent if DST is not used.
                   C :== [A-Z][A-Z]*

               Example for my location in Boulder, Colorado, USA:
                   TZ=MST-420MDT


            4. The DST variable has 0 or 2 parts in the string.  It has
               zero if no Daylight Saving Time is observed or 2, when DST
               starts and ends, for those places that do observe it.  I
               have been unable to locate any place in the world that has
           1, 3, or more changes per year to its local time.  If DST
           is not null, the string means:

                 dst1 = a string that describes when DST starts
                 dst2 = a string that describes when DST stops

               Both have the syntax of "mmddDhhMM%CCcc".  Translating it:

                 mm  = the month (January = 01)
                 dd  = the day of the month (01 to 31)
                 D   = the "search-forward" function number
                   (0-7) usually 1 or 0
                         0 = use the day mm/dd without translation
                         1 = search forward to the first Sunday
                         2 =        "                    Monday
                         3 =        "                    Tuesday
                         4 =        "                    Wednesday
                         5 =        "                    Thursday
                         6 =        "                    Friday
                         7 =        "                    Saturday
                 hh  = the hour at which the change goes into effect
                   (00-23) usually 01, 02 or 03
                 MM  = the minute at which the change goes into effect
               (00-59) usually 00
                 %   = a '+' or a '-' saying what direction to move
                 CC  = how many hours to move (00-23) usually 01 or 02
                 cc  = how many minutes to move (00-23) usually 00

               Example for my location in Boulder, Colorado, USA in 1986:
                   DST="042410200+0100  102510200-0100"
               Alternately, if I already know the exact dates that DST
           starts and ends for that year, I can use:
                   DST="042700200+0100  102600200-0100"


            5. If the file is unreadable or missing, the default time
           zone to use is GMT and the default DST is null.


            6. The library call "localtime()" is the only system code
               that need interpret the TZ and DST variables.


            7. TZ and DST are put into the environment of each user
               when the user logs in.  A user can change create their
               own TZ and DST values and replace the system maintained
               values in their environment.

            8. Those utilities that strip off environment information
               can obtain TZ and DST values by reading "/etc/TIMEZONE".



    Bob Devine
    [phone]
    Burroughs Distributed Systems Group
    6655 Lookout Road
    Boulder, CO. 80301

    UUCP: ihnp4!seismo!hao!asgb!devine OR sdcrdcf!bmcg!asgb!devine

Volume-Number: Volume 5, Number 47

From jsq  Wed Feb 12 11:16:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 12 Feb 86 17:16:01 GMT
Draft-9: TZ.P.046

Date: Wed, 12 Feb 86 04:26:15 EST
>From: Chris Torek <[e-mail]>

I have tried to stay out of this discussion since I know little of
existing time zone standards and have never needed anything but
the 4BSD system time zone.  However, I would like to ask that the
following suggested rule be amended:

>4. The DST variable has 0 or 2 parts in the string.  It has
>   zero if no Daylight Saving Time is observed or 2, when DST
>   starts and ends, for those places that do observe it.  I
>   have been unable to locate any place in the world that has
>   1, 3, or more changes per year to its local time.

Rest assured that the moment this became a standard and everyone
conformed to it (comments upon the likelyhood of that eventuality
notwithstanding), Murphy would strike and Congress would legistlate
some really crazy DST rules.

I see no good reason for requiring the string to have exactly 0 or
2 parts (efficiency of specific implementations does not count as
a good reason).

(I suspect also that once this were standardised, someone would
come up with a time zone name that requires a digit or a plus or
minus sign, making rule 3 unworkable as well....)

Chris

Volume-Number: Volume 5, Number 48

From jsq  Thu Feb 13 10:59:21 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 13 Feb 86 16:59:03 GMT
Draft-9: TZ

>From: harvard!cybvax0!vcvax1!paul (Paul Kleppner)
Date: Wed, 12 Feb 86 18:58:56 est

Bob Devine's proposal on the /etc/TIMEZONE format (volume 5, #47)
looks to me like a good solution to a complicated problem.
I do have one suggestion, though: don't clutter the /etc/TIMEZONE file
with Bourne shell syntax.  If the file contained only the two actual values
(separated by a space or tab) and not the "TZ=", "DST=",
and "export" comands, it would be much easier to read by non-Bourne
shells or by other programs, which would otherwise have to filter
out the shell statements.

I should point out that there is no loss in efficiency with this approach.
The login initialization file /etc/profile, instead of containing the line,

    . /etc/TIMEZONE

would contain the lines

    read TZ DST < /etc/TIMEZONE
    export TZ DST

(I believe this will work correctly whether DST has 0 or 2 parts.)
------------
Paul Kleppner
VenturCom, Inc.
617/661-1230
{seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul

Volume-Number: Volume 5, Number 49

From jsq  Fri Feb 14 06:12:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 14 Feb 86 12:12:31 GMT
Draft-9: TZ.P.046

Date: Fri, 14 Feb 86 00:51:16 PST
>From: sun![e-mail] (Guy Harris)

>      The major points of the proposal are:
>
>            1. There is a world-readable, superuser-modifiable file
>               named "/etc/TIMEZONE" that describes the per-system
>               timezone information and Daylight Saving Time rules.

Too specific.  The standard should not give all the implementation details.
Giving this much detail merely constrains an implementation to use the
particular technique specified, even if it isn't the appropriate technique
to use (on a V7 or 4BSD system, for instance, fetching it from the kernel is
more appropriate, since it's already there).

>            3. The TZ variable has 2 required parts (and an optional 3rd):
>
>               A = standard abbreviation for the timezone as used by the
>                local area
>                    A :== [A-Z][A-Z]*
>               B = plus or minus difference in minutes from Universal Time,
>               plus for those locations east of GMT, minus for west
>                   B :== [+-][0-9][0-9][0-9]
>               C = standard abbreviation for the timezone as used by the
>                local area when Daylight Saving Time is in effect.  This
>            part of TZ may be absent if DST is not used.
>                   C :== [A-Z][A-Z]*

Unnecessarily incompatible with System V, which specifies the offset from
Universal Time in hours.  (It also requires you to multiply an offset in
hours by 60, which is much better done by a computer.)  See below for a
better way of specifying offsets which aren't an integral number of hours.

>            4. The DST variable has 0 or 2 parts in the string.  It has
>               zero if no Daylight Saving Time is observed or 2, when DST
>               starts and ends, for those places that do observe it.

Not sufficient.  The routines that convert between GMT and local time can be
given a time not in the current year; if the time is in a year prior to the
current one, these routines must still be able to convert it, and must
therefore know the rules for all years prior to the current one.  (The
4.2BSD source indicates that the rules for 1970, 1971, and 1972 in Australia
were all rather different; 1970 had no daylight savings time, 1971 had it
from October 31 to the end of the year, 1972 had it from January 1 to
February 27 and October 31 to December 31, and all subsequent years had it
January 1 to March 7 and October 31 to December 31.  In the US, of course,
we had the infamous "nixonflag" for 1974 and 1975....)  For times in the
future, of course, it will have to rely on a projection (if it could handle
times in the future exactly, I'd put it to work on Sun's stock price...).

>            7. TZ and DST are put into the environment of each user
>               when the user logs in.
>
>            8. Those utilities that strip off environment information
>               can obtain TZ and DST values by reading "/etc/TIMEZONE".

What puts TZ and DST into the environment of each user?  If it's not done by
"login", then every program which is used as a login shell must do it.  A
LOT of UNIX systems have many users who log in to a specific application,
which may never run the shell.  As such, it should be done by "login", which
makes the Bourne shell syntax unhelpful.

And what about utilities not run by a logged-in user?  Must they look in
"/etc/TIMEZONE"?  If so, do they have to do their own parsing?  There is
already a routine in System V called "tzset()", which sets the global
variables "timezone" and "daylight".  In vanilla S5, it just scans the TZ
environment variable (which means you have to go through contortions to get
that variable set).  In systems which have a source for time zone
information other than TZ, they can scan TZ if present and non-null, and use
that source otherwise.  In your proposal, "tzset()" should scan that file.
However, we have now eliminated the need for any program to look at
"/etc/TIMEZONE" directly - they should let "tzset()" do it for them.

The trouble is that there are several ways of storing the time zone
information, other than in the TZ environment variable.  V7 stored it,
in effect, in "/unix"; you specified it when you built your kernel.  4.2BSD
also stores it there (in "/vmunix", actually); you can specify it when you
build your kernel, but you can also specify it with the "settimeofday"
system call.  A system running on a machine with an EEPROM might store the
time zone there, and either read it out when the machine is booted or make
it readable by user programs.  A "hosted" system (i.e., a system which
provides a P1003-compatible environment on top of an existing operating
system) might be able to get it out of the host operating system.  A table
containing this operation might be mapped into the address space of all
processes in any of a number of ways, depending on the memory model of the
OS and the whims of the OS's designers.

It's inappropriate to commit to something as specific as "/etc/TIMEZONE";
"tzset()" should be specified as fetching the appropriate information and
setting the "timezone", "daylight", and "tzname" external variables (System
V-style) and also arranging, somehow, for the daylight savings time rules to
be set up.

The only copy of the X3J11 C standard draft I can get my hands on right now
is an old one.  It lists "asctime", "ctime", "gmtime", and "localtime" as
being like their UNIX versions, but doesn't list "tzset", "timezone",
"daylight", or "tzname".  Presumably, it considers them to be part of the
operating system (or environment) rather than the C language/library.  (Have
they been added in later drafts?)  If they haven't been added in later
drafts, I propose that P1003 adopt the System V versions, as specified in
the System V Interface Definition, with the following change:

change

    ...the external variable "daylight" is non-zero only if the
    standard U.S.A. Daylight Savings Time conversion should be
    applied.  The program compensates for the peculiarities
    of this conversion in 1974 and 1975; if necessary, a table
    for these years can be extended.

    If an environment variable named TZ is present, "asctime" uses the
    contents of the variable to override the default time zone.  The
    value of TZ must be a three-letter time zone name, followed
    by an optional minus sign (for zones east of Greenwich) and
    a series of digits representing the difference between local time
    and Greenwich Mean Time in hours; this is followed by an
    optional three-letter name for a daylight time zone.

to

    ...the external variable "daylight" is non-zero only if the
    standard Daylight Savings Time conversion for the current time
    zone, if any, should be applied.  The external variable "tzname"
    contains pointers to the name of the time zone when daylight
    savings time is    not in effect and when it is in effect in its
    first and second members, respectively.

    The default time zone is settable by the system administrator,
    and is usually the time zone that the majority of the system's
    users are in.  "tzset" normally sets the variables "timezone",
    "daylight", and "tzname" to the values for the default time zone.
    If an environment variable named TZ is present, "tzset" sets the
    variables "timezone", "daylight", and "tzname" from the value
    of this environment variable.  The value of TZ must either be
    of the form "GMT+hh[:mm]", or "GMT-hh[:mm]", specifying an
    unnamed time zone "hh" hours and "mm" minutes ahead of or behind
    Universal Time (if "mm" is not present, it is assumed to be
    zero), or a zone name followed by an optional minus sign (for
    zones east of Greenwich) and a specification of the form "hh[:mm]"
    specifying the difference between local time and Universal Time
    in hours and minutes; this is followed by an optional name for the
    time zone when Daylight Savings Time is in effect.  A time zone name
    must not contain any digits and must not contain the characters "+",
    "-", or ":".  If an unnamed zone is specified, Daylight Savings
    time rules are considered not to apply, and the time zone name is
    assumed to be the value of the TZ environment variable.

I include the "GMT+/-hh:mm" specification on the assumption that there are
unnamed time zones; if this is not so, this part may be deleted.  Note that
unlike the System V TZ value, this permits time zone names to be longer or
shorter than 3 characters.  It also permits fractional-hour time zone
offsets; it uses a different syntax than the one described in the "FUTURE
DIRECTIONS" section, because that section doesn't indicate whether the
time zone offset must be four digits (which would mean that EST5EDT would no
longer be valid) or not (which would mean that OLT7ODT would be ambiguous -
is Out to Lunch Time 7 hours away from GMT or 7 minutes?).  The proposed
syntax is an upward-compatible extension of the current syntax, which the
syntax in the "FUTURE DIRECTIONS" section is not.

If TZ is not set, "tzset" will presumably get the Daylight Savings Time
rules from some standard place (where it gets them from is an implementation
detail which does not belong in P1003).  If TZ is set, there should be some
indication of where it gets the DST rules from.  It can either get them from
some "standard" database of rules, or from an environment variable (either
from additional data at the end of TZ, or from DST), or both (i.e., if the
rules aren't specified in an environment variable, it uses the time zone
specified in TZ to look up the rules in the standard database).

Volume-Number: Volume 5, Number 50

From jsq  Tue Feb 18 14:59:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 18 Feb 86 20:59:02 GMT
Draft-9: TZ.P.046

Date: Sun, 16 Feb 86 00:31:47 cst
>From: ihnp4!uiucdcs!ccvaxa![e-mail] (Andy Glew)

Pardon me if I've missed anything in this discussion, but has anyone
considered the possiblity of double daylight savings time - not just
two hours offset, but 2 hours in the deep of summer and one hour in
spring and fall (or, one hour's saving in summer, none in fall, and
an "unsaving" in deepest winter).

[ I don't recall anyone mentioning that before.  -mod ]

Volume-Number: Volume 5, Number 51

From jsq  Tue Feb 18 15:03:09 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 18 Feb 86 21:02:52 GMT
Draft-9: TZ.P.046

>From: hao!asgb![e-mail] (Bob Devine)
Date: Mon, 17 Feb 86 18:00:40 mst

>>From: Chris Torek <[e-mail]>

>>Discussion of (1) why Daylight Saving Time should not be constrained
>>to either 0 or 2 changes per year; and (2) cautioning against a
>>timezone name that may contain numerals, '+', or '-'.  Both points
>>emphasized the possibility of future bizarre changes.


  Yes, I was aware and worried about both problems.  However, in my
search of timezones and DST rules worldwide I was not able to find any
current or past rules that would have violated the assumptions.  Future
rules are unlikely to break the current conventions for fear of confusing
everybody (it's bad enough now).

  Parsing the strings for TZ _COULD_ be done using reserved characters
but that would really break the old usage of the TZ environment variable.
I'm hoping to only bend it.  Likewise, the library call that interprets
the DST strings _COULD_ be written in a generalized fashion to handle any
number of DST changes per year.  However, I don't think such effort is
required.

Bob Devine
(BTW, Sys V spell doesn't have "timezone" in its dictionary.)

Volume-Number: Volume 5, Number 52

From jsq  Wed Feb 19 21:31:33 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
References: your article <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 20 Feb 86 03:31:19 GMT
Draft-9: TZ.P.046

>From: seismo!umcp-cs!aplvax!osiris!phil (Philip Kos)


> Bob Devine
> (BTW, Sys V spell doesn't have "timezone" in its dictionary.)


Neither does 4.2, at least on our Pyramid.

Phil Kos
The Johns Hopkins Hospital, Baltimore, MD

Volume-Number: Volume 5, Number 53

From jsq  Thu Feb 20 08:14:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 20 Feb 86 14:14:02 GMT
Draft-9: TZ.P.046

Date: Wed, 19 Feb 86 17:58:51 est
From: seismo!cbosgd.ATT.UUCP!mark (Mark Horton)

>  Yes, I was aware and worried about both problems.  However, in my
>search of timezones and DST rules worldwide I was not able to find any
>current or past rules that would have violated the assumptions.  Future
>rules are unlikely to break the current conventions for fear of confusing
>everybody (it's bad enough now).

You haven't looked hard enough.  Also, the minute you make an assumption,
some congressman or some MP in Britain or Japan or wherever will violate it.

>>>Discussion of (1) why Daylight Saving Time should not be constrained
>>>to either 0 or 2 changes per year;

There is a thing called "Double Daylight Time" which does exactly that.
I think it happened a few years back in some other country (Canada?)
Surely someone on this list can provide details.

>>>and (2) cautioning against a
>>>timezone name that may contain numerals, '+', or '-'.  Both points
>>>emphasized the possibility of future bizarre changes.

On the contrary, the notion of giving a time zone a name is an American
notion.  They also have names in Europe and Australia, but my impression
is that in many parts of the world, such as Japan, time zones are named
according to the ISO format +HHMM, e.g. Japan is +0900.

I'm afraid the variable TZ is already pretty badly broken - it can't be
used in Newfoundland or Central Australia or Saudi Arabia.  (We do have
sites on Usenet in Newfoundland - as far as I know, they all run 4BSD.)

elsie!ado has written some code with a much more flexible structure
(and some additional complexity, which I think is unavoidable.)  I
understand he's going to submit it to this group shortly.  I think
it merits serious consideration.  How much goes into the standard and
how much is left to the implementor isn't clear (e.g. is the format
of the time zone description file part of the standard?) but the code
is intended to be public domain, and it ought to make a good start.

    Mark

Volume-Number: Volume 5, Number 54

From jsq  Fri Feb 21 13:12:10 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 21 Feb 86 19:11:54 GMT
Draft-9: TZ.P.046

From: seismo!kobold!ncr-sd!greg
Date: Thu, 20 Feb 86 19:54:17 pst
Organization: NCR Corporation, Rancho Bernardo

In article <4186@ut-sally> Bob Devine proposes a standard method to hold
the timezone information, which keeps the information in a file in a format
suitable for interpretation by the (Bourne) shell.

In article <[e-mail]> Guy Harris replies:
>        ....
>Too specific.  The standard should not give all the implementation details.
>        ....
>Unnecessarily incompatible with System V, which specifies the offset from
>        ....
>Not sufficient.  The routines that convert between GMT and local time can be
>        ....
>What puts TZ and DST into the environment of each user?  If it's not done by
>        ....
>And what about utilities not run by a logged-in user?  Must they look in
>        ....

I agree; the scheme is flawed by all of those problems and more.  I don't
have any skill with words (in the way they are used in specifications), but
I would propose that any scheme adopted by the standards commitee should have
the following requirements:
  -  There should be a way that a system administrator could specify a global
     (system-wide) default that is not process-tree related.  In other words,
     it can't depend upon something in the environment.
  -  There should be a way that this can be overridden so that non-default
     timezones can be supported.  Presumably, this can be done on a process-
     tree basis; i.e., it can be carried in the environment.
  -  It should be possible to handle things like multiple timezone changes
     per year (double daylight savings, like during WWII) and timezone changes
     that are not exactly one hour (didn't Newfoundland once have a daylight
     savings change of 1.5 hours?).

Personally, I think a better scheme is the one presented here a month or so
ago, where the timezone information lives in a directory with one file for
each timezone and with the standard timezone linked to a default name.  A user
could override the default by specifying one of the files in an environment
variable, or roll his own file and specify the full path name.  The file
would contain:
  -  The timezone offset and default name.
  -  The rules for the normal conversion and the name for it.
  -  Exceptional periods, the offset, and the name.
Here I am being too specific myself, but I wanted to point out that Bob Devine
has done us a great service by articulating a mechanism for describing the
normal conversion (the second point above); whether this information is to
be included in the file and processed on the fly or pre-processed by some
program into a binary table that can be evaluated quickly is an implementation
consideration.

-- Greg Noel, NCR Rancho Bernardo    [e-mail] or [e-mail]

Volume-Number: Volume 5, Number 55

From jsq  Fri Feb 21 13:14:14 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: TZ yet again
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 21 Feb 86 19:14:02 GMT
Draft-9: TZ

Date: Thu, 20 Feb 86 13:11:50 est
From: Davidsen <seismo!rochester!steinmetz!davidsen>

I posted some thoughts on TZ previously, but I don't believe they got out,
due to a mail problem at that time. Forgive me if you've heard this before.

Some of the problems with TZ are:
    1) non-standard names and abbreviations
    2) strange DST rules
    3) (1) and (2) change or may be added to.

Posible Solution #1:
-------------------

  One method of solving these problems would be to use the value of TZ as
the name of a file in a special directory. These files would be
executable, and given the current date and time in GMT would return the
number of minutes to be added to GMT for that timezone (obviously the
return value is signed).

Drawbacks:
  The only obvious one I see is overhead. A directory search + execution
is not nearly as nice as just getting a number from the environment. I
don't have a good idea what it would add as a percentage to the execution
time of localtime(). Since the time may change at any given instant, the
system can not just execute each program once and save the result.

Advantages:
  Any number of timezones may be used, and timezones may be added or
deleted easily. If performance is really an issue (I'm not convinced
either way), then the directory could be cached in some way.

  The algorithm may be easily changed and any level of complexity can be
handled. Programmers can handle more complexity than politicians.

Posible Solution #2:
-------------------

  Add another form of the TZ variable which contains all the information
needed to handle the current algorithm. One posible form of this would be:
    TZ=M:D:DOW:h:m:Name/Offset [;TZ=M:D:DOW:H:M:Name/Offset ...]

Where: (times in GMT)
     M - month of the change
     D - date of the change, as a value or range (ie "14" or "14-20")
   DOW - day of the week, a value, range, or "*".
     h - hour of the change
     m - minute of the change
  Name - the correct abbreviation for "date", etc.
Offset - signed minutes to add to GMT

Advantages:
  This would be faster than posible solution #1.

  The string can contain any number of changes.

  Portable (all change times in GMT), and users at sites on site specific
time can "roll their own".

  Covers the case where two locations want to use the same abbreviation
for "their" timezone. Note that this keeps the computer from getting
confused, not the user.

Disadvantages:
  May not be able to handle some future really complex algorithm,
particularly one based on something like phase of the moon. However, this
can be updated on a yearly basis.

  Ugly, hard to read.

Summary
-------
  These are proposals for comment. Since I have not presented them as
final solutions, technical comments are more useful than raving flames.
They are not intended to address the problem of what time is used for
crontab, at, and uucp calls, but I see no reason to think that either
solution would exacerbate these problems, in fact solution #1 might be set
to always return local time (and ignore TZ) if the caller was root, bin,
uucp, etc.

Volume-Number: Volume 5, Number 56

From jsq  Sun Feb 23 11:19:24 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 23 Feb 86 17:19:07 GMT
Draft-9: TZ.P.046

From: seismo!elsie!ado
Date: Fri, 21 Feb 86 22:48:58 EST

# To unundle, sh this file
echo README 1>&2
cat >README <<'End of README'
@(#)README    1.4

The shell archive of which this file is a part contains man pages for functions
and a file format designed to deal with Daylight Savings Time variations.

The basic idea is to have a system-wide directory that contains binary files
describing time zone rules; functions such as "localtime" could read such
files before doing time conversions.

A manual page for a "time zone compiler" that turns text-file descriptions of
time zone rules into binary files is also included, as is a sample input file
for the compiler.  These would, of course, not be part of the standard;
they are included here only to show that the binary files that would be used
under this scheme can be readily created.

Source code for these functions and for the time zone compiler are available
from seismo!elsie!ado, the person to whom to direct comments (with, perhaps,
carbon copes to cbosgd!mark and seismo!philabs!linus!encore!necis!geo,
who are responsible for any good ideas that show up here).
End of README
echo settz.3 1>&2
cat >settz.3 <<'End of settz.3'
.TH SETTZ 3
.SH NAME
settz, newctime, newlocaltime \-  convert date and time to ASCII
.SH SYNOPSIS
.nf
.B settz(zonename)
.B char *zonename;
.PP
.B char *newctime(clock)
.B long *clock;
.PP
.B
#include "time.h"
.PP
.B struct tm *newlocaltime(clock)
.B long *clock;
.PP
.B char *tz_abbr;
.SH DESCRIPTION
.I Settz
sets time zone information used by
.I newctime
and
.IR newlocaltime .
If
.I zonename
begins with a slash,
it is used as the absolute pathname of the
.IR tzfile (5)-format
file from which to read the time zone information;
if
.I zonename
begins with some other character,
it is used as a pathname relative to the standard time zone information
directory.  A call of the form
.ti +.5i
.B
settz("")
.br
causes built-in information about GMT to be used; a call of the form
.ti +.5i
.B
settz((char *) 0)
.br
is treated as if it were a call of the form
.ti +.5i
.B
settz("localtime")
.PP
.I Newlocaltime
has the same argument and return value as
.IR localtime .
If
.I newlocaltime
is called before
.I settz
is called,
.I newlocaltime
calls
.I settz
with the value returned by
.B
getenv("TZ").
.I Newlocaltime
sets
tz_abbr
to a pointer to an
ASCII string that's the time zone abbreviation to be used with
.IR newlocaltime 's
return value.
.PP
.I Newctime
returns a pointer to a string of the form
.ti +.5i
Sat Feb 15 15:45:51 1986 EST\\n\\0
.br
where the last (variable-width) field is the time zone abbreviation.
.SH DIAGNOSTICS
.I Settz
returns zero if all seems well; it returns negative one otherwise
(and sets things up so that its built-in information about GMT is used).
.SH FILES
/etc/tzdir    standard time zone information directory
.SH "SEE ALSO"
ctime(3), getenv(3), tzfile(5)
.. @(#)settz.3    1.3
End of settz.3
echo tzfile.5 1>&2
cat >tzfile.5 <<'End of tzfile.5'
.TH TZFILE 5
.SH NAME
tzfile \- time zone information
.SH SYNOPSIS
.B
#include "tzfile.h"
.SH DESCRIPTION
The time zone information files used by
.IR settz (3)
and
.IR newlocaltime (3)
have the format of the
.I tzinfo
structure described in the include file
.B
"tzfile.h":
.sp
.nf
.in +.5i
struct tzinfo {
    int    tz_timecnt;
    long    tz_times[TZ_MAX_TIMES];
    char    tz_types[TZ_MAX_TIMES];
    struct dsinfo {
        long    ds_gmtoff;
        char    ds_abbr[TZ_ABBR_LEN+1];
        char    ds_isdst;
    }    tz_dsinfo[TZ_MAX_TYPES];
};
.fi
.PP
The
.B tz_timecnt
field tells how many of the
.B tz_times
and
.B tz_types
stored in the file are meaningful.
Each of the meaningful
.B tz_times
entries is a starting time (as returned by
.IR time (2));
the same-indexed
.B tz_types
entry is the index of the
.B tz_dsinfo
array element that tells about how "local time" is generated starting at that
time.
For a file to be used by
.IR settz ,
its
.B tz_times
entries must be sorted in ascending order.
.PP
In the
.B tz_dsinfo
structures,
.B ds_gmtoff
gives the number of seconds that should be added to GMT;
.B ds_abbr
is the ASCII-NUL-terminated string used as the time zone abbreviation;
and
.B
ds_isdst
tells whether
.B
tm_isdst
should be set by
.IR newlocaltime (3).
.PP
.I Newlocaltime
uses the first element of
.B tz_dsinfo
if either
.B tz_timecnt
is zero or
.IR newlocaltime 's
argument is less than
.BR tz_times[0] .
.SH SEE ALSO
settz(3)
.. @(#)tzfile.5    1.4
End of tzfile.5
echo tzcomp.8 1>&2
cat >tzcomp.8 <<'End of tzcomp.8'
.TH TZCOMP 8
.SH NAME
tzcomp \- time zone compiler
.SH SYNOPSIS
.B tzcomp
[
.B \-d
directory ] filename ...
.SH DESCRIPTION
.I Tzcomp
reads text from the file(s) named on the command line
and creates the time zone information files specified in this input.
If a
.I filename
is
.BR ` - ',
the standard input is read.
.PP
This option is available:
.TP
.B \-d directory
Create time zone information files in the named directory rather than
in the standard directory named below.
.PP
A sharp characters (#) in the input introduces a comment which extends to
the end of the line the sharp character appears on.
Any line which is blank (after comment stripping) is ignored.
Non-blank lines are expected to be of one of three
types:  rule lines, zone lines, and link lines.
.PP
A rule line has the form
.nf
.B
.ti +.5i
.ta \w'Rule 'u +\w'MostNA 'u +\w'FROM 'u +\w'1973 'u +\w'TYPE 'u +\w'Apr 'u +\w'lastSun 'u +\w'2:00 'u +\w'SAVE 'u
.sp
Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
.sp
For example:
.ti +.5i
.sp
Rule    MostNA    1969    1973    -    Apr    lastSun    2:00    1:00    D
.sp
.fi
The fields that make up a rule line are:
.TP
.B NAME
Gives the (arbitrary) name of the set of rules this rule is part of.
.TP
.B FROM
Gives the first year in which the rule applies.
.TP
.B TO
Gives the last year in which the rule applies.
The word
.RB ` only '
may be used to repeat the value of the
.B
FROM
field.
.TP
.B TYPE
Gives the type of year in which the year applies.  If
.B TYPE
is
.B
"-"
then the rule is taken to apply in all years between
.B FROM
and
.B TO
inclusive.
If
.B TYPE
is something else, then the command
.B
.ti +.5i
years from to type
.br
is executed with arguments
.IR from ,
.IR to ,
and
.IR type
taken from the rule line; the rule is taken to apply only in those years
printed by the
.I years
command.

The distributed
.I years
command is a shell script that can handle year types
.B uspres
(United States presidential election years)
and
.B nonpres
(all other years);
other year types may be added by changing the script.
.TP
.B IN
Names the month in which the rule takes effect.  Month names may be
abbreviated.
.TP
.B ON
Gives the day on which the rule takes effect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'lastSun  'u
5    the fifth of the month
lastSun    the last Sunday in the month
lastMon    the last Monday in the month
Sun>=8    first Sunday on or after the eighth
Sun<=25    last Sunday on or before the 25th
.fi
.in -.5i
.sp
Names of days of the week may be abbreviated or spelled out in full.
Note that there must be no spaces within the
.B ON
field
(or within any other field).
.TP
.B AT
Gives the time of day at which the rule takes affect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'1:28:13  'u
2    time in hours
2:00    time in hours and minutes
15:00    24-hour format time (for times after noon)
1:28:14    time in hours, minutes, and seconds
.fi
.in -.5i
.sp
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in
effect.  This field has the same format as the
.B AT
field.
.TP
.B LETTER/S
Gives the "variable part" (for example, the 'S' or 'D' in "EST" or "EDT")
of time zone abbreviations to be used when this rule is in effect.
If this field is
.B
"-",
the variable part is null.
.PP
A zone line has the form
.sp
.nf
.ti +.5i
.ta \w'Zone 'u +\w'Eastern 'u +\w'GMTOFF 'u +\w'MostNA 'u
Zone    NAME    GMTOFF    RULES    FORMAT
.sp
For example:
.sp
.ti +.5i
Zone    Eastern    -5:00    MostNA    E%sT
.sp
.fi
The fields that make up a zone line are:
.TP
.B NAME
The name of the time zone.
This is the name used in creating the time zone information file for the zone.
.TP
.B GMTOFF
The amount of time to add to GMT to get standard time in this zone.
This field has the same format as the
.B AT
and
.B SAVE
fields of rule lines;
begin the field with a minus sign if time must be subtracted from GMT.
.TP
.B RULES
The name of the rule(s) that apply in the time zone.
If this field contains
.B
"-"
then standard time always applies in the time zone.
.TP
.B FORMAT
The format for time zone abbreviations in this time zone.
The pairs of characters
.B
"%s"
is used to show where the "variable part" of the time zone abbreviation goes.
.PP
A link line has the form
.sp
.nf
.ti +.5i
.ta \w'Link 'u +\w'LINK-FROM 'u
Link    LINK-FROM    LINK-TO
.sp
For example:
.sp
.ti +.5i
Link    Eastern        EST5EDT
.sp
.fi
The
.B LINK-FROM
field should appear as the
.B NAME
field in some zone line;
the
.B LINK-TO
field is used as an alternate name for that zone.
.PP
Lines may appear in any order in the input.
.SH EXAMPLE
[Since a sample time zone file appears in the shell archive,
this section has been omitted.]
.SH FILES
/etc/tzdir    standard directory used for created files
.SH "SEE ALSO"
settz(3), tzfile(5)
.. @(#)tzcomp.8    1.4
End of tzcomp.8
echo tzinfo 1>&2
cat >tzinfo <<'End of tzinfo'
# @(#)tzinfo    1.5

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    MostNA    1969    1973    -    Apr    lastSun    2:00    1:00    D
Rule    MostNA    1969    1973    -    Oct    lastSun    2:00    0    S
Rule    MostNA    1974    only    -    Jan    6    2:00    1:00    D
Rule    MostNA    1974    only    -    Nov    24    2:00    0    S
Rule    MostNA    1975    only    -    Feb    23    2:00    1:00    D
Rule    MostNA    1975    only    -    Oct    26    2:00    0    S
Rule    MostNA    1976    2037    -    Apr    lastSun    2:00    1:00    D
Rule    MostNA    1976    2037    -    Oct    lastSun    2:00    0    S

# Almost surely wrong:

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    Oz-Eur    1969    1973    -    Apr    lastSun    2:00    1:00    S
Rule    Oz-Eur    1969    1973    -    Oct    lastSun    2:00    0    -
Rule    Oz-Eur    1974    only    -    Jan    6    2:00    1:00    S
Rule    Oz-Eur    1974    only    -    Nov    24    2:00    0    -
Rule    Oz-Eur    1975    only    -    Feb    23    2:00    1:00    S
Rule    Oz-Eur    1975    only    -    Oct    26    2:00    0    -
Rule    Oz-Eur    1976    2037    -    Apr    lastSun    2:00    1:00    S
Rule    Oz-Eur    1976    2037    -    Oct    lastSun    2:00    0    -

# New names

# Zone    NAME        GMTOFF    RULES    FORMAT
Zone    Atlantic    -4:00    MostNA    A%sT
Zone    Eastern        -5:00    MostNA    E%sT
Zone    Central        -6:00    MostNA    C%sT
Zone    Mountain    -7:00    MostNA    M%sT
Zone    Pacific        -8:00    MostNA    P%sT
Zone    Yukon        -9:00    MostNA    Y%sT
Zone    Hawaiian    -10:00    MostNA    H%sT
Zone    Newfoundland    -3:30    -    NST
Zone    Japan        9:00    -    JST
Zone    WET        0    Oz-Eur    WE%sT
Zone    MET        1     Oz-Eur    ME%sT
Zone    EET        2    Oz-Eur    EE%sT
Zone    AEST        10:00    Oz-Eur    AES%sT
Zone    ACST        9:30    Oz-Eur    ACS%sT
Zone    AWST        8:00    -    AWST    # No Daylight Saving here?

#
# A settz("") uses the code's built-in GMT without going to disk to get
# the information.  Still, we want things to work if somebody does a
# settz("GMT"), so. . .
#

Zone    GMT        0    -    GMT

# Old names

# Link    LINK-FROM    LINK-TO
Link    Eastern        EST5EDT
Link    Central        CST6CDT
Link    Mountain    MST7MDT
Link    Pacific        PST8PDT

# "Pacific Presidential Election Time" is being contemplated in Congress

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
Rule    Twilite    1969    1973    -    Apr    lastSun    2:00    1:00    D
Rule    Twilite    1969    1973    -    Oct    lastSun    2:00    0    S
Rule    Twilite    1974    only    -    Jan    6    2:00    1:00    D
Rule    Twilite    1974    only    -    Nov    24    2:00    0    S
Rule    Twilite    1975    only    -    Feb    23    2:00    1:00    D
Rule    Twilite    1975    only    -    Oct    26    2:00    0    S
Rule    Twilite    1976    2037    -    Apr    lastSun    2:00    1:00    D
Rule    Twilite    1976    1987    -    Oct    lastSun    2:00    0    S
Rule    Twilite    1988    2037    uspres    Oct    lastSun    2:00    1:00    PE
Rule    Twilite    1988    2037    uspres    Nov    Sun>=7    2:00    0    S
Rule    Twilite    1988    2037    nonpres    Oct    lastSun    2:00    0    S

# Zone    NAME        GMTOFF    RULES    FORMAT
Zone    New-Pacific    -8:00    Twilite    P%sT

# Next really belongs in a separate file

Link    Eastern        localtime
End of tzinfo
exit
--
    UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie![e-mail]
    DEC, VAX and Elsie are Digital Equipment and Borden trademarks

Volume-Number: Volume 5, Number 57

From jsq  Sun Feb 23 11:40:51 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 23 Feb 86 17:40:38 GMT
Draft-9: TZ.P.046

Date: Sat, 22 Feb 86 21:14:28 cst
From: ihnp4!uiucdcs!ccvaxa![e-mail] (Andy Glew)

I do not know if double daylight savings has ever been used,
but I heard a man from Canada's NRC talking about it on CBC radio last year.
The NRC is hoping that the US will go to DST earlier and stay later,
and from that it is only a short step to double time.
This makes better sense the closer you get to the pole.
I do know that several industries in Britain in WWII went to effective
double daylight savings time, by having people report to work earlier
in deepest summer (which is what we should do anyway).

What's all the fuss about, anyway? All times should be recorded in GMT,
since it's the closest thing we have to a standard clock.
Timezone information should only be used for local printing of the time
- dates, ls, etc. For this, the environment variable would be useful.

[ Several people have described what the problems are at length.
Since it's been a while, naturally there are people just starting
to follow the discussion who missed its beginning.  Perhaps I should
repost one of the explanatory articles.  So, a small poll:  If you've
come in late and want to know what all the fuss is about, send me
a note.  If you've been following the discussion all along and remember
a particular specification of the problem which was most clear to you,
let me know.  If I get enough of the former I will repost an
explanatory article, possibly chosen according to the latter.  -mod ]

Timestamps MUST be recorded in GMT, for projects that exchange code across
timezones.

[ The UNIX kernel has always kept internal time in GMT, as have most
other operating systems (VMS seems to be an exception).  There are,
however, programs which write text timestamps in local time.  -mod ]

It is conceivable that knowing what time of his local day the author last
modified his code might be useful, but instead of carrying a timezone
indication, why not carry a true location around, like latitude/longitude,
and look that up in a database (although it might get hairy for spaceships
travelling near c :-).

[ Timezones change per latitude and longitude. -mod ]

Even hairier idea:  have we considered non-24 hour days? Someday, someone is
going to have computers on the moon; they may still be running UNIX (and
Fortran, and Cobol) at that time, and there's no guarantee that they'll
stick to a 24 hour day. There've been a lot of studies that show that men
in isolation go to a 28-30 hour cycle, and without the sun rising to keep
you in synch, there's no reason not to change the definition of "day".
GMT will probably still be kept, but local time takes on a whole new meaning.
Maybe just leave an escape in any timezone environment variable for
local time conversions that don't simply consist of adding an offset?

[ Doubtless it will happen, but probably not within the effective
life of the current P1003 proposed standard.  I suggest the new
INFO-FUTURES list for such discussions.  I will repost the announcement
from UNIX-WIZARDS for it as the next article.  -mod ]

Andy "Krazy" Glew. Gould CSD-Urbana.
UUCP: ...!ihnp4!uiucdcs!ccvaxa!aglew
ARPA Internet: [e-mail]

[ PS:  Other than interpolating comments, there are exactly two things
which I can't resist doing to submitted articles before posting them
and without asking their authors first:  fixing obviously incorrect
spelling; and fixing incorrect network addresses, like UUCP addresses
given as being for USENET or old-style ARPANET addresses which won't
work anywhere in the ARPA Internet where domain nameservers are in use.
-mod ]

Volume-Number: Volume 5, Number 58

From jsq  Sun Feb 23 11:48:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Announcement of INFO-FUTURES
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 23 Feb 86 17:48:01 GMT
Draft-9: INFO-FUTURES

[ The following is reposted from UNIX-WIZARDS.  -mod ]

From: [e-mail] (Barry Shein)
Date: 17 Feb 86 18:56:14 GMT



 INFO-FUTURES        Sunday February 16, 1986    Volume 1 Number 1

  Purpose: To provide a speculative forum for analyzing current and
  likely events in technology as they will affect our near future in
  computing and related areas.

    This is a moderated list, submissions should be sent to:

        ARPA:    [e-mail]
        CSNET:    info-futures@bu-cs
        UUCP:    ...harvard!bu-cs!info-futures

    Membership and address changes to info-futures-request

---------------------------------------------------------------------------

             ANNOUNCEMENT OF INFO-FUTURES

This list has been formed to fill a need that appeared to not really
be served by any existing list. Although the topics it addresses are
often touched upon in almost every other major forum the goal is to
provide a place for more eclectic and speculative discussions
generally discouraged in technical newsgroups. The original discussion
for formation of this list occurred among readers of the unix-wizards
mailing list, the desire for such a forum seemed obvious. I hope the
source of participation spreads far beyond the original discussions
from which this list was founded.

In broad terms, topics of interest include developments in both
computing research and industry which are likely to affect our
decision making, particularly decisions we are probably grappling with
right this minute. Technologies can change so rapidly that simply
forecasting for needs within any organization one or two years in
advance can be extremely difficult, frequently we are forced to
provide foundations that effectively lock us into a technology for
longer periods of time. I would hope the information this list
provides can help both the practitioner and researcher determine where
best to expend resources.

It is difficult, probably impossible, to separate what is often termed
'politics' or 'religion' from facts in such a discussion.  Those that
believe in a particular future and proceed to implement it will often
find their prophecies to be self-fulfilling, it will become their
future and the future of those whom they influence.  My only hope is
that, through moderation, we can provide a steady flow of information
who's content is apparent and useful. I have never felt uncomfortable
with people who are excited about their ideas.

Feel free to post this announcement on other bulletin boards.

        Moderator
        Barry Shein
        Boston University

Volume-Number: Volume 5, Number 59

From jsq  Mon Feb 24 09:26:50 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ yet again
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 24 Feb 86 15:26:38 GMT
Draft-9: TZ

Date: Sun, 23 Feb 86 23:54:47 PST
From: seismo!s3sun!sdcsvax!sdcsvax.UCSD.EDU!allyn (Allyn Fratkin)

In article <[e-mail]>, [e-mail] (Davidsen) writes:
>   One method of solving these problems would be to use the value of TZ as
> the name of a file in a special directory. These files would be
> executable, and given the current date and time in GMT would return the
> number of minutes to be added to GMT for that timezone (obviously the
> return value is signed).

Problem here: on most unix systems the parent only gets the lower eight
bits of the exit value.  This would mean max/min values of 127/-128.
Not very practical if the value is supposed to be in minutes.
Fine if the return value is in hours, though, but then you're still
leaving parts of the world out.  Besides, we've pretty much decided that
we should at least have precision in minutes.

Of course, we could make the precision HALF-hours.  This is kind of silly,
but is there anywhere in the world whose time is not an integral number of
half hours away from GMT?

[ The canonical example is Saudi Arabia, which has other problems, too. -mod ]

By the way, I definitely feel that we need both a per-system time zone
and a per-process (or per-user) time zone.  Machines are stationary,
but users are mobile (and sometimes far away).

(I imagine that timezone is not in the dictionary because its not a word).

[ Is filesystem a word?  -mod ]

--
 From the virtual mind of Allyn Fratkin            [e-mail]    or
                          UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn

 "Generally you don't see that kind of behavior in a major appliance."
--
Allyn Fratkin                    [e-mail]
UCSD EMU/Pascal Project          or
U.C. San Diego                   {ucbvax, decvax, ihnp4}!sdcsvax!allyn

Volume-Number: Volume 5, Number 60

From jsq  Tue Feb 25 22:02:30 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 26 Feb 86 04:02:15 GMT
Draft-9: TZ.P.046

From: Jack Jansen <seismo!mcvax!jack>
Date: 25 Feb 86 20:56:12 N (Tue)
Organization: AMOEBA project, CWI, Amsterdam

Well, even though the discussion doesn't seem to have anything
to do with standardising, it *is* interesting.

[ Comments on how to handle timezones are explicitly requested
in an appendix of the current P1003 draft.  -mod ]

I like the outside of elsie!ado's proposal, but I think the
implementation could be done more simple and cheap.

First (not too important), if you go for binary files, you
shouldn't put two arrays of fixed size in the beginning.
This will inevitably mean trouble for future generation. If you
*do* insist on binary data, make it variable sized array, and
put a count in.

Second, and most important, I think the method is far too complex
for its achievements. I think something along the following
lines would work as easy, and be much simpler to set up:
- view normal time and dst as *different* timezones. If a certain
  area has had more than one dst offset since written history(jan70),
  see those as different too. Note that different timezones could
  have the same name.
- Per timezone, keep a list with transition-times, and new timezones.
- Further, use a scheme along the lines of elsie!ado's proposal, so
  use files in a specified directory, and use a link to get the
  local default time.
Now, two typical files would look like:
/etc/tz/FOT:
    # FOT - Far Out Time.
    FOT    +11:28        # Offset from GMT
    Apr 1, 1970    FST
    Apr 1, 1971    FST
    Apr 1, 1972    FST.1972
    ...
/etc/tz/FST:
    # FST - Far out Summer Time.
    # Differs by 1:10 hour from FST.
    FST    +12:38
    Sep 1, 1970    FOT
    ...
/etc/tz/FST.1972:
    # FST.2 - Far out Summer Time exceptional situation for 1972.
    # Differs 1:11 hour from FOT.
    FST    +12:39
    Sep 1, 1972    FOT
Note that these files should be in binary, of course, and transition
times in order of ascending magnitude.
Also, if you do a settz("FST"), and present a date in november,
a quick binary search will immedeately get you to the Sep 1 transition,
and get you to the right timezone. Note that this will *also* work for
timezones with the same names: the name in col. 2 of the files, and in
the settz() call, are filenames, and the first entry in the file is
the name that will be used on output.

--
    Jack Jansen, [e-mail]
    The shell is my oyster.

Volume-Number: Volume 5, Number 61

From jsq  Wed Feb 26 10:57:08 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 26 Feb 86 16:56:45 GMT
Draft-9: TZ.P.046

From: seismo!hao!asgb!devine (Bob Devine)
Date: Tue, 25 Feb 86 19:58:51 mst

  First of all, sorry for the length of this article.  I've been
doing job search type of things the last week.

  It appears that this will be my last posting from this site.
The Burroughs Distributed Systems Group was severely cut for budget
reasons.  The uucp site "asgb" (it stood for Advanced Systems Group,
Boulder) will soon be no more.  In fact, there are only a few
terminals left attached to any VAX.  Our site officially closed
a week and a half ago.

  There has been many responses to my proposal for the handling
of timezones and Daylight Saving Time rules.  Let me respond to
them according to subject.  However, let me first reiterate the
important ideas presented in my proposal of a month ago:

    1. a single timezone definition exists for that system;
       this definition is the default

    2. timezone and DST rules are kept and passed as
       environment variables

    3. a user (or program) can override the default definition

  The above can be considered a "cleaned-up" way of handling timezone
compared to AT&T System III and V.  DST handling is just an analogous
extension to this.  I proposed this method to deal with the coming
UNIX usage throughout the world.  Specifically, the product line we
were developing used UNIX and was to be offered everywhere Burroughs
does business.

  My proposal's biggest (and intended) limitation is its inability to
deal with past years at all.  To do that requires a table of such
changes as elsie!ado's proposes.  However, after I started collecting
such rules and saw that they numbered in the thousands I decided for
the simpler proposal.  If anyone wants to, they can see my collection
gathered from a person from the DOT, someone at the National Bureau of
Standards, and several publications from the American Federation of
Astrologers.  However, any collection becomes old quickly.  For example,
China just this month started using 4 timezones instead of the one
centered on Bejing.

  On to the criticisms and questions:

1. Format of proposed DST variable.  Are 0 or 2 changes per year
   sufficient? (Chris Torek, Mark Horton and Andy Glew)
   I believe so for all places __currently__.  The only places that
   I have found to use Double Summer Time are:
       Argentina     1924 and 1969
       Azores        1942 (unclear)
       France        some areas 1940-42
             everywhere 1943-46 and 1976-77
       Great Britain 1941-47
       Portugal      1942
       Spain         1942-1946
       Tunisia       194x (unclear)

   If Double Summer Time is in modern use, four changes can be put
   into the DST variable.  Re-reading my response to Chris Torek,
   I see that I was unclear.  I wrote that no rules would "violate the
   assumptions" made for the DST variable.  What was not clear was
   the assumption that 4 changes could be used.

2. Numerals, '-', or '+' in timezone names. (Chris Torek and Mark Horton)
   I don't know.  Does anyone have a list of legal timezone names
   and abbreviations (if any) as used by each country?  I have English
   equivalents for some.  The TZ variable can be modified to use
   field separator characters between the names and offset from UT.
   A note: the sign used for the offset should match ISO standards,
   which is the opposite of System V conventions.  Sorry, I don't have
   the ISO document number than details this; it's in a box somewhere.

3. "/etc/TIMEZONE" is too specific.  Use functions. (Guy Harris)
   For the purpose of P1003, Guy is right.  To avoid the confusion
   of all new CTIME(3C) functions, the existing functions should be
   kept though with modifications.  A problem lurks in the use of
   the ctime() function where programs copy the returned string into
   a too short array.

4. Proposed TZ format is too unlike Sys V's. (Guy Harris)

   System V's use of difference is hours is just plain wrong for
   many places (eg., Dominican Republic, Iran, and Saudi Arabia
   where local custom dictates midnight is when the sun sets).
   I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
   where "H" is hours and "m" is minutes.  It's a matter of choice.
   It may be preferable to use seconds to be on the safe side.


5. Who puts TZ and DST into a user's environment? (Guy Harris)

   The easy answer is "whatever puts TZ there now".  It is an OS
   specific mechanism.  "login" could do it or a user's login shell
   upon starting up could do it.  I didn't specify in the proposal.


6. What about utilities not run by a logged-in user? (Guy Harris)

   Such utilities should only have to use a library call to obtain
   the timezone name (if desired) and the local time.


7. Use files to hold information about that timezone.
   (steinmetz!davidsen and ncr-sd!greg (Greg Noel))

   Using a file with the name of a timezone won't work for Daylight
   Saving Time rules because one timezone may span multiple countries
   with its named unchanged (eg., Canada and USA) yet the countries may
   have different rules for daylight saving time.  Furthermore, within
   one country, not all areas within a timezone use DST the same way
   (eg., Indiana, Arizona).  A two dimensional grid of timezones and
   countries might be possible but this would probably get unwieldy quickly.
   For users of network file systems and diskless workstations: beware,
   proximity does not imply same rules (for a bad dream, think of a network
   that spans a timezone where there is only one file server and the rest
   of the nodes are diskless -- this contrived example is hard to solve
   with any proposal).
   The second point is that the name of the timezone has to be known
   somehow -- both the default timezone and, if the user selects one,
   the non-system name.  This brings to mind an easy solution of
   environment variables.


  Let me close with the requirements, as I see them, for the handling of
timezone and DST information.  It might be better to debate these instead
of any specific proposals.

1. every site must have default information on its timezone and for DST rules
2. information about the past, while it may be needed in some situations,
   is not essential
3. information about other timezones and areas, while it may be needed
   in some situations, is not essential
4. a user (or program) should be allowed to change the timezone and DST
   information for their use only
5. because the local time conversion is used often, it should be fast
6. changes to the system-default information should be easy to make

So long,
Bob Devine
(home phone: [phone])

Volume-Number: Volume 5, Number 62

From jsq  Thu Feb 27 19:50:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 28 Feb 86 01:50:05 GMT
Draft-9: TZ.P.046

Date: Thu, 27 Feb 86 15:11:34 PST
From: seismo!sun!guy (Guy Harris)

>   My proposal's biggest (and intended) limitation is its inability to
> deal with past years at all.

You *intended* to make "ctime" only work on times in the current year?  This
is extremely undesirable.  Every UNIX out there can deal with this now, and
people have probably written code that depends on being able to do so.  That
code won't work on a system which doesn't support this.

> 4. Proposed TZ format is too unlike Sys V's. (Guy Harris)
>
>    System V's use of difference is hours is just plain wrong for
>    many places (eg., Dominican Republic, Iran, and Saudi Arabia
>    where local custom dictates midnight is when the sun sets).
>    I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
>    where "H" is hours and "m" is minutes.  It's a matter of choice.

It is not in the least "a matter of choice".  For one thing, I'd rather let
the computer do the multiplication of 8 by 60 instead of being forced to do
it myself; computers are good at that sort of thing.  For another, my
proposal is an *upward compatible extension* to the System V syntax (which,
BTW, the item in the System V Interface Definition under "Future
Directions", where the number in TZ becomes a four-digit value of the form
"hhmm", does not seem to be).  Your proposal is not an upward compatible
extension to the System V syntax, as it involves changing the time zone
offset to minutes - i.e., EST5EDT is no longer correct.  There have already
been enough incompatible changes to UNIX by several groups with the intent
of "improving" it (Berkeley's CSRG and AT&T's USDL have both done their
share of this); let's try to keep that sort of thing to a minimum in the
future.  (I.e., don't always take the first solution to a problem that comes
to mind, or even the most aesthetically pleasing solution; sacrificing some
think time or some aesthetic merit for compatibility is almost always the
right thing to do.)

>    It may be preferable to use seconds to be on the safe side.

Given that most clocks used in everyday situations aren't accurate to the
second, the chances of a timezone offset being specified to the second are
somewhere between slim and none, unless you have an offset from UTC
specified to the second due to something like not picking up a leap second
(which I sincerely doubt anybody does).  Specifying the offset down to the
second is overkill (note that 4.2BSD's "gettimeofday" system call fills in a
structure which specifies the offset to the minute; a commendable example of
restraint).

> 5. Who puts TZ and DST into a user's environment? (Guy Harris)
>
>    The easy answer is "whatever puts TZ there now".  It is an OS
>    specific mechanism.  "login" could do it or a user's login shell
>    upon starting up could do it.  I didn't specify in the proposal.
>
> 6. What about utilities not run by a logged-in user? (Guy Harris)
>
>    Such utilities should only have to use a library call to obtain
>    the timezone name (if desired) and the local time.

In this case, the library call in question had better be part of the
standard.  I presume by "the local time" you really meant "the local
timezone offset and the daylight savings time rules for that zone".  As
such, since this implies there is a "default" time zone, why not have all
the routines use this time zone if TZ is not specified in the environment?
That way, 1) programs don't have to "know" that they're going to be run in
such an environment and have the extra calls to get the "default" timezone
information added, and 2) you don't have to bother sticking TZ in the
environment unless you want to work in a timezone other than the default.

> 7. Use files to hold information about that timezone.
>    (steinmetz!davidsen and ncr-sd!greg (Greg Noel))
>
>    Using a file with the name of a timezone won't work for Daylight
>    Saving Time rules because one timezone may span multiple countries
>    with its named unchanged...

Arthur Olson's proposal does not require the file's name to be the same as
the zone.  The zone's name is computed from information in the file.

>    For users of network file systems and diskless workstations: beware,
>    proximity does not imply same rules (for a bad dream, think of a network
>    that spans a timezone where there is only one file server and the rest
>    of the nodes are diskless -- this contrived example is hard to solve
>    with any proposal).

No, it isn't.  Here's how it could be solved, given the way Sun
sets up diskless clients:

    Have the "default time zone" be specified in a file (whether the
    file is a "profile" file which puts it in the environment, or
    a file which is read in by the "get default timezone" routine,
    or whatever is irrelevant) which is, say, in "/etc".  Make it
    a symbolic link to a file in "/private/etc".  "/private", on Sun
    systems, is a small private file system on the server; each client
    has one of its own, to hold things like "/etc/rc.boot" which sets
    the host name for the machine.  Sharing this file between all clients
    obviously won't work, so the precedent for configuration files for
    diskless workstations which can't be shared by all clients of its
    server is already established.

>    The second point is that the name of the timezone has to be known
>    somehow -- both the default timezone and, if the user selects one,
>    the non-system name.  This brings to mind an easy solution of
>    environment variables.

It may be easy, but it's not a solution, unless you can stuff this default
timezone into the environment of every process on the system.  And if you do
so in N different places, as System V currently does, it may be a solution
but it's not easy.

>   Let me close with the requirements, as I see them, for the handling of
> timezone and DST information.  It might be better to debate these instead
> of any specific proposals.

If we're going to debate the requirements, let's not see any specific
proposals until the requirements are settled, so we don't have to shoot down
proposals which either don't meet the requirements or which are more complex
than is needed to meet the requirements (or both!).

> 1. every site must have default information on its timezone and for DST
>    rules

Every *host* must have this information, as you pointed out in the example
of the diskless workstatiions.

> 2. information about the past, while it may be needed in some situations,
>    is not essential
> 3. information about other timezones and areas, while it may be needed
>    in some situations, is not essential

Would you please explain the distinction between "needed" and "essential"?
If it is truly "needed" in some situations, as opposed to "useful", it's
"essential" unless the system can do without a P1003-compatible system.

> 4. a user (or program) should be allowed to change the timezone and DST
>    information for their use only

4 1/2. a consequence of this is that a program must be able to override
       any setting the user has made and get the default timezone for
       that machine

Volume-Number: Volume 5, Number 63

From jsq  Fri Feb 28 09:42:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: TZ suggestion (clarification)
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 28 Feb 86 15:42:28 GMT
Draft-9: TZ

Date: Thu, 27 Feb 86 11:05:13 est
From: Davidsen <seismo!rochester!steinmetz![e-mail]>

When I used the term "returned value" in reference to the method of executing
timezone programs, I assumed use of a pipe as a posibility to get an
indefinite quantity of info back from the process. Thanks to Allyn Fratkin for
requesting clarification (or mentioning the need for it).

Volume-Number: Volume 5, Number 64

From jsq  Sat Mar  1 17:31:45 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: localtime(), ctime() and timezones
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 1 Mar 86 23:31:29 GMT
Draft-9: TZ

Date: 02 Mar 86 05:47:32 +1100 (Sun)
From: Robert Elz <munnari![e-mail]>

It seems to me that this discussion is getting a bit overblown,
as far as P1003 is concerned, it doesn't really seem to be
as difficult or complex as some people are making out.

So, I'm going to propose something that could be inserted into
P1003 (with the obvious extra definitions that I'm going to
leave out on the assumption that everyone knows what they are,
like the definition of a "struct tm").

In some words of other, it would go like this (with hopefully
a lot of cleaning up of the typography to get rid of quotes
and things like that where I would really prefer to use italics
or bold):

Implementations shall provide the following functions:

    struct tm *gmttime(t) time_t *t;
    struct tm *localtime(t) time_t *t;
    int settz(p) char *p;
    char *asctime(tp) struct tm *tp;
    char *ctime(t) time_t *t;

gmttime: converts the time_t "*t" to a "struct tm" representing
the same time (in Universal Co-ordinated Time).  (waffle about
the returned value being in a static area, etc, goes here).

localtime: converts the time_t "*t" to a "struct tm" representing
the given time adjusted to represent some local time difference.
"local time" will be specified by a call to "settz", if no such
call has preceded the call to localtime(), localtime() will call
"settz(getenv("TZ"));".  Implementors should note that for any defined
past time (from midnight January 1, 1970 until the time the call is made)
the local time returned should be accurate (taking into account the effects
of daylight saving, if any).  For future times, the local time returned
should be as likely to be accurate as current projections of
future timezone rules and daylight saving time changes allow.

settz: enables users to specify the local time conversion to be
used by localtime.  The string is an implementation specific
representation of the timezone offset desired, with 2 special
cases..  The null pointer (t == (char *)0) will always select
the appropriate local time offset for the host executing the call.
A null string (t != (char *)0 && *t == '\0') will select
no local time transformations (making localtime() equivalent
to gmttime()).  Implementations should provide, and document,
some mechanism to allow users to select another timezone.
This mechanism is beyond the scope of the standard.  Implementors
should, if possible, allow users to define their own timezones,
and not restrict them to use one of some standard set.
If settz is called with an unrecognisable argument, the effect
is implementation defined.  (Users might expect any of three
"reasonable"? actions could be taken here -- use GMT, use local time,
or use local time in the area where the implementation was performed).
settz returns 0 if the timezone selected could be obtained, and
-1 otherwise.  settz can be called as many times as needed, each
call affects future calls of localtime, until another call to settz.

acstime: returns a 25 character string representing the time
specified by "*tp".  The format of the string is ... (you all know it).

ctime: is defined to be "asctime(localtime(t))".

...................

Notes: this is (about) the right level of detail for the standard.
There is no need to specify what the form of the argument to
settz() is.  This enables things like the Sys V "EST5EDT" string,
and Arthur Olson's (elsie!ado) "localtime" "Eastern" etc, to all
be used with impunity - the implementor gets to choose whatever
is appropriate to him - just provided that he can satisfy the
needs of his customers (implementors who provide no means of getting
daylight saving right in the Southern hemisphere can probably
expect not to sell many copies there - but that's their choice).

In particular - this discourages programmers from writing programs
which "know" what the local time should be - there's no reason at
all why a program should ever need to do more than select GMT,
host local time, or a user specified time zone.  (nb: while localtime
uses the TZ environment variable in cases where the program has made
no call to settz(), there's nothing to stop a program getting the
argument to settz() from anywhere it pleases, including from several
different environment variables if it chooses, and needs to operate
in several timezones, or from an external configuration file, or
wherever is appropriate).

This works for existing programs (in general) - localtime() performs
the required call to settz() the first time it is called (directly
or via ctime()).  There's no need to worry about who sets TZ, if
its not set, getenv("TZ") will return (char *)0 and settz() will
then use the appropriate local time for the host.  How settz()
gets that information is an implementation matter.  The security
problems (people faking local time for programs that expect it
to be host local time, by setting TZ before running the program)
can easily solved by causing those (comparatively few) programs
to do "settz((char *)0)" before their first call to localtime().

What's missing:  So far here there is no mention of the "timezone name".
None of the standard mechanisms is really adequate here.  The V7
(and 4.xbsd) "timezone" function is clearly inadequate (although
4.2 bsd allows users to set the environment variable TZNAME to anything
they like) since there can clearly be several possible names for the
same offset, and "timezone" has no way to discover which one is wanted.
Requiring the name to resice in the environment somewhere (Sys V) is also
inadequate (there are too many problems about making sure it is set
in all the right places).

Arthur Olson's scheme causes "localtime" to set a global variable
"tz_abbr" to the correct string name for the timezone just used.
I can't think of any cases where anything more than this is needed,
but it is less flexible then "timezone()" and it would require
programs that currently call timezone() to have to be altered.
(He also has his version of "ctime" (but not "asctime") include
the timezone in its output - I doubt if that is feasible for P1003,
too many existing programs know what every byte in the returned
string from ctime() contains.)

I solicit suggestions for what to do here - one might be to
retain "timezone" but not require that it be capable of returning
anything except the zone name corresponding to the last call of
localtime() - then with ado's implementation it could simply
ignore its arguments and return tz_abbr - I suspect that would
satisfy all existing uses (and the ones it doesn't are quite
likely not to work in general anyway).  Opinions?

There's also no discussion of how this relates to processes
and images.  Not because there's anything doubtful here,
but just because the necessary words take a lot of space.
(informally, "the first call to localtime" is intended to
be "the first after the program is exec'd, ignoring any
fork()'s it may have since performed, as long as there
has been no subsequent exec).  Getting this kind of thing
right is essential for a standatds document, its not essential
here.

...................

A justification for all this ...  Today, just about 2 1/2 hours ago
(it's early on a Sun morning as I write this) the daylight saving
rules changed in at least 2 Australian states (no-one really seems
very sure of what happened, or really why).  The politicians gave
us less than a month's warning that it was coming (and the month
was February, which isn't a long month...).

If there's anyone who doesn't believe that some form of dynamic
timezone setting is required, they're welcome to come to Australia
and suffer our local politicians (this isn't the first time: a
couple of years ago New South Wales decided to extend daylight
saving for a month to try and save on power bills - the amount of
notice given was about the same - at that time, at least one local
site decided to scrap running on GMT and run on localtime (ala VMS)
instead.  They're still doing that, I think, and suffering because
of it).

I'm extremely grateful that Arthur Olson decided to try an implementation,
and donate it to the community - he made the task of converting things here
much easier than it otherwise would have been.  His implementation
meets the above specs (in fact, it inspired them...), and will work
for all the contorted exampes that people have been proposing (multiple
shifts in a year, multi-hour saving, even daylight wasting).

But note - there's no need for the standard to require this
generality, market pressures will do that - all the standard
needs to do is supply a suitable interface.  Arthur Olson's
implementation proves that the above reccomendation is
implementable (munnari is running his code, in libc, right now)
and effecient enough.

[ Your last sentence gives the reason that I've encouraged
discussions of implementations in the newsgroup:  it's good
to know that a proposed standard is implementable and handles
actual cases.  But you're right, of course, that the
P1003 standard doesn't need implementation details.  -mod ]

Jack Jansen's (mcvax!jack) somewhat similar, but slightly different scheme
would probably work just as well.

Bob Devine's (hao!asgb!devine) "I don't think its needed" attitude
can also fit the standard - if he's right then he's probably going
to have a very fast localtime() which will serve him well.
If he's wrong, then he's not going to get many customers.

That's good - the more the better - that gives us users (or us system
implementors perhaps) a wide choice of methods.

Robert Elz        [e-mail]    seismo!munnari!kre

Volume-Number: Volume 5, Number 65

From jsq  Thu Mar  6 11:13:01 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Daylight Time Survey Summary
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 6 Mar 86 17:12:15 GMT
Draft-9: TZ.Daylight.Time

Date: Tue, 4 Mar 86 16:02:04 PST
From: Snoopy <[e-mail]>

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

From jsq  Fri Mar  7 10:30:39 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: localtime(), ctime() and timezones
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 7 Mar 86 16:30:16 GMT
Draft-9: TZ

Date: 6 Mar 86 23:09:30 EST (Thu)
From: floyd!opus![e-mail] (Kenneth Almquist)
Organization: Bell Labs, Holmdel, NJ

I basicly agree with Robert Elz.  A few comments:

1)  I suggest adding an entry for the timezone name to the tm
structure.  Something like

    char tm_zone[6];

I expect that time zone names will not exceed 5 characters, although
the size of this array need not be specified in the standard.  I don't
suggest making tm_zone a character pointer because if that were done
any implementation would be complicated by the need to ensure that
tm_zone was still valid after settz was called with a different time
zone.

2)  The routine name is gmtime, not gmttime.

3)  Removing the explicit mention of a time zone directory from the
standard means that there is no longer a way to find the offset of time
zone that a time zone name represents.  How about providing a routine
to do this:

    long tzoffset(tzname)  char *tzname;

which takes a time zone name and returns the offset of that time zone
in seconds with respect to GMT?
                Kenneth Almquist
                ihnp4!houxm!hropus!ka    (official name)
                ihnp4!opus!ka        (shorter path)

Volume-Number: Volume 5, Number 67

From jsq  Sat Mar  8 14:15:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time conversion
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 8 Mar 86 20:15:39 GMT
Draft-9: TZ

Date: Sat, 8 Mar 86 13:14:34 EST
From: elsie![e-mail]

Source for the time zone compiler discussed here earlier has been posted to
mod.sources.  The new posting incorporates changes suggested by net readers:

*    "newctime" now returns a pointer to a string of exactly the
    same form as that returned by "ctime"--no time zone abbreviation
    appended.

*    the format of "time zone information files" has been changed so that
    the files can hold descriptions of arbitrarily large size.

I agree with munnari!kre--certainly the P1003 standard ought not require
conforming implementations to provide exhaustive time conversion capabilities;
kre's note about what the standard actually might look like is a good starting
place.  Still, the standard ought to allow folks to do arbitrary time
conversion if they want to; the mod.sources posting should provide both an idea
of just how arbitrary governments have been (and can be expected to be) in
defining "local time," and an idea of the sort of mechanism that would be
required to deal with this arbitrariness.
--
    UUCP: ..decvax!seismo!elsie!ado        ARPA: elsie![e-mail]
    DEC, VAX, Elsie & Ado are Digital, Borden & Shakespeare trademarks.

Volume-Number: Volume 5, Number 68

From jsq  Sun Mar  9 21:10:27 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Daylight Time
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
In-Reply-To: <[e-mail]>
Date: 10 Mar 86 03:10:09 GMT
Draft-9: TZ.Daylight.Time

Date: Sat, 8 Mar 86 13:26:00 pst
From: <trwrb!desint!geoff> (Geoff Kuenning)
Organization: SAH Consulting, Manhattan Beach, CA

Hey, you guys, don't forget us futurists!  In particular, I have the
following problem to solve, which is why I'm following this discussion:

    In 'at', I have to be able to figure out the GMT equivalent of an
    arbitrary date/time pair for the future.

So please, please, don't simply disregard the future in your suggestions.

[ But please try to keep it relevant to the current P1003 Trial Use standard
or the upcoming Full Use one.  E.g., let's keep relativity out of it.  -mod ]
--

    Geoff Kuenning
    {hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 5, Number 69

From jsq  Tue Mar 18 16:47:31 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: guest moderator
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 18 Mar 86 22:47:13 GMT
Draft-9: mod.std.unix

I will be away the rest of the week in California for the USENIX board meeting.
The guest moderator meawhile will be John B. Chambers, who returns tomorrow
from a USENIX program committee meeting in California.  Have fun, John....

Volume-Number: Volume 5, Number 70

From jsq  Mon Mar 24 15:10:03 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Thanks g.m.; End of Volume 5
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 24 Mar 86 21:09:52 GMT
Draft-9: mod.std.unix

Well, I think John did an emminently succesful job with all
the submissions he received while I was gone (i.e., none).
He liked it so much he's volunteered to do it again while
I'm away at the Florence P1003 meeting in April.

This is the last article of Volume 5.

Volume-Number: Volume 5, Number 71