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

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

From jsq  Mon Mar 24 15:22:43 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 6
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 24 Mar 86 21:22:31 GMT
Draft-9: mod.std.unix

This is the first article in Volume 6 of mod.std.unix/std-unix.
These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee 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.  I'm also the institutional representative
of the USENIX Association to P1003.

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {gatech,harvard,ihnp4,seismo,pyramid,sequent}!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., through 5.
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 6, Number 1

From jsq  Mon Mar 24 15:39:59 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: 24 Mar 86 21:39:42 GMT
Draft-9: mod.std.unix

This article is a slightly adapted copy of an earlier one.

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 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.

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 6, Number 2

From jsq  Mon Mar 24 15:57:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Time Zones; D6 A.3
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 24 Mar 86 21:56:55 GMT
Draft-9: TZ

[ This is a reposting of the article which started the time zone
discussion.  Remember a few things when reading it.  UNIX (and many
other operating systems) has *always* kept internal time in GMT.
That is not the issue.  The issue is how to present local times to the
users.  And, while it is good to know how to implement a scheme for
handling time zones, the P1003 standard only needs to include a few
library routine interfaces.  Finally, this subject is getting sort of
discussed out, so let's try not to repeat it all again.  -mod ]

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 6, Number 3

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

From: [e-mail] (VLD/VMB)
Date:     Tue, 25 Mar 86 10:57:52 EST

Not all users of a particular system are necessarily in the
same time zone.

[ Right.  And past times back at least to the UNIX epoch have
to be accounted for.  There are possibly a few other points of
that sort which weren't mentioned in the original article.  -mod ]

Volume-Number: Volume 6, Number 4

From jsq  Thu Mar 27 17:07:51 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: write eof
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 27 Mar 86 23:07:29 GMT
Draft-9: 6.4.2

From: [e-mail] (Michael Gersten)
Date:    Wed, 26 Mar 86 22:54:22 PST
Organization: Ucla Computer Club (disclaimer)

This is a request for proposal.

One thing unix REALLY needs is a 'write eof' ability.

In particular, how about
int writeeof(int fd);

which takes a file discriptor as an argument, returns an int
(for the purpose of success/failure), and does the following:

On a pipe: indicates thaat a read at that point should return EOF
without advancing the read pointer (or advancing it beyond the EOF marker).
Purpose: To allow filter program to filter more than just a single
command (ex: filter | csh. csh will then run other commands, whose
standard input will be output of filter. EOF could be used to terminate
such commands)

On a regular file: Indicate that the file should be truncated to this
point, and excess space freed by the system.
Purpose: obvious.

On a special file (mag tape): Write an end of tape marker
Purpose: obvious

On all other files: Either implementation defined or return(-1) if
nothing.


Note: This is my own opinion. It is not that of the UCLA computer club,
nor of UCLA in general. But I bet there are a lot of unix hacks
out there who just might be interested in this.
            Michael Gersten
--
disclaimer | ihnp4!ucla-cs!cc1 | Michael Gersten | Joke: 412

Volume-Number: Volume 6, Number 5

From jsq  Fri Mar 28 10:05:05 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003 publicity, Denver minutes, Draft 7, future meetings
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 28 Mar 86 16:04:53 GMT
Draft-9: Access.Standards D7.Access P1003.schedule

At the Denver meeting of the P1003 working group, it was decided to
publish a summary of the minutes of each meeting shortly afterwards
in mod.std.unix, in the USENIX newsletter ;login, and in UNIX Review,
if possible.  The USENIX board, at their Napa meeting last week,
expressed strong interest in having that in ;login (they're also
looking for technical papers).  I haven't approached UNIX Review yet.

The Denver minutes have been delayed due to logistical reasons,
but I expect to see them some time next week and will then work
on a summary to post.

The Denver meeting was used to resolve most remaining balloting
objections to Draft 6.  The result of that and of some further changes
made after communication with balloters will be Draft 7, which has
taken longer than expected to produce due to the sheer volume of
balloting comments.  Draft 7, with some minor formatting changes,
should soon be published in paper form by IEEE as the Trial Use
Standard.  An on-line copy which "represents" Draft 7 will likely
be made available through this newsgroup some time next week.

There are three more meetings of the IEEE P1003 working group this year:

    16-18 April    Florence, Italy, the week before EUUG
    9-11 June    Atlanta, Georgia, the week of USENIX
    ? September    Palo Alto, California, still tentative

There will presumably also be a meeting just before the winter
USENIX convference, which will probably be in Washington, D.C.
in February 1987.

Volume-Number: Volume 6, Number 6

From jsq  Sat Mar 29 11:35:42 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: 1003.1 Trial Use Standard to be published in April
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 29 Mar 86 17:35:28 GMT
Draft-9: Trial.Use

I have received this from the committee chair:

    We have Standards Board Approval.  The 1003.1 Trial Use Standard is
    now offical. (1003.2 will be used to denote the shell/tools document).
    We will have published copies in Mid-April ... cost $19.95, with bulk
    purchasing discounts available.  Contact:

        IEEE Service Center
        445 Hose Ln.
        Piscataway, NJ 08854

    ask for 1003.1 Standard - stock number SH10546

Volume-Number: Volume 6, Number 7

From jsq  Sat Mar 29 20:37:18 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: writeeof()
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 30 Mar 86 02:37:06 GMT
Draft-9: 6.4.2

From: [e-mail] (VLD/VMB)
Date:     Sat, 29 Mar 86 0:57:42 EST

I don't think P1003 should be trying to invent new facilities.

[ I don't see anywhere in the original posting where such was suggested.
Nor does an article appearing in this newsgroup imply that P1003 is
going to act on it.  See Volume 6, Number 2.  -mod ]

Suggestions like this should probably be forwarded to the
UNIX-WIZARDS (net.unix-wizards) mailing list.

[ Maybe.  I was so pleased to see *anything* that wasn't on timezones....
-mod ]

In the case of writeeof(), suppose you write an EOF 1M bytes
into a regular disk file, then write another 2M bytes into the
same file, then read the file.  According to the suggestion,
the first EOF would be gone (implementation would probably
also require this).  But in the pipe example, multiple EOFs
would stay around and be detected upon reading the pipe.
(At least using stream i/o, one could conceivably slip an EOF
control packet into the pipe stream, so this is implementable.)
But look:  Files and pipes would not behave the same; why
weaken one of UNIX's strongest design strengths unnecessarily?

I suppose one could argue more reasonably for the inclusion
of a truncate() primitive, to shorten an existing file of
any type; Fortran could use this.  On the other hand, why
encourage the use of Fortran on UNIX?

Volume-Number: Volume 6, Number 8

From jsq  Mon Mar 31 15:56:01 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: writeeof()
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Spencer W. Thomas)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Date: 31 Mar 86 21:55:01 GMT
Draft-9: 6.4.2

From: [e-mail] (Spencer W. Thomas)
Date: Sun, 30 Mar 86 17:22:21 MST
Organization: University of Utah CS Dept

Of course, 4.[23] BSD already has a ftruncate() primitive, which does
exactly what the original poster wants on files.  One could presumably
make it have "EOF" semantics when applied to pipes (since the behavior
there is currently an error).

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

Volume-Number: Volume 6, Number 9

From jsq  Wed Apr  2 06:22:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.1 Trial Use Standard to be published in April
Message-Id: <[e-mail]>
Organization: IEEE/P1003 Portable Operating System Environment Committee
In-Reply-To: <[e-mail]>
Date: 2 Apr 86 12:22:43 GMT
Draft-9: Trial.Use

From: gatech![e-mail] (Gene Spafford)
Date: Tue, 1 Apr 86 21:25:37 EST
Organization: Software Engineering Research Center (SERC), Georgia Tech

In article <[e-mail]> you write:
>I have received this from the committee chair:
>
>    We have Standards Board Approval.  The 1003.1 Trial Use Standard is
>    now offical. (1003.2 will be used to denote the shell/tools document).
>    We will have published copies in Mid-April ... cost $19.95, with bulk
>    purchasing discounts available.  Contact:
>
>        IEEE Service Center
>        445 Hose Ln.
>        Piscataway, NJ 08854
>
>    ask for 1003.1 Standard - stock number SH10546
>

I'm dyslexic sometimes, too -- that's supposed to be "445 Hoes Lane"

Cheers,
--gene

Volume-Number: Volume 6, Number 10

From jsq  Mon Apr  7 17:16:49 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to standards-related documents
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Apr 86 23:16:27 GMT
Draft-9: Access.Standards

From: mtsbb![e-mail] (Lee Vallone)
Date: Mon, 7 Apr 86 13:13:48 cst
Subject: mod.std.unix

I was reading mod.std.unix for the first time and would appreciate
if you could clarify some things for me.

1)  What is the aim of P1003?  What is P1003.

[ It's often called the UNIX Standards Committee, but its real name is
IEEE 1003 Portable Operating System for Computer Environments Committee.
(I've finally remembered to update the Organization line from the former
name of Portable Operating Systems Environment Committee.)
It's a descendent of the /usr/group Standards Committee that
produced the /usr/group Standard, which is based on System III.
Many of the same people are on the IEEE 1003 committee.

According to the Foreword of the current P1003 document:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

The Abstract adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

P1003 Draft 7 has just been approved as the 1003.1 Trial Use Standard.
(1003.2 will be used to denote the shell/tools document.)
Published copies will be available in mid-April at $19.95,
with bulk purchasing discounts available.  Contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

Ask for 1003.1 Standard - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year, after which a Full Use Standard will be produced.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Charles River Data Systems
        983 Concord St.
        Framingham, MA 01701
        decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    15-18 April    Florence, Italy (the week before EUUG)
    9-11 June    Atlanta, Georgia (the week of USENIX)
    ? September    Palo Alto, California?
    ? February 1987    Washington, D.C. (the week of USENIX)

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.
-mod ]

    Is this supposed to be a new standard that is
    not equivalent to either BSD4.x or SYS V?

[ Yes and no.  It is not precisely the same as any existing system,
but it has been carefully designed to not outlaw any major variant,
including not only System V and 4.2BSD, but also hosted systems,
networked systems, etc.  Representatives of major vendors of both
System V and 4.2BSD are on the committee.  -mod ]

    Or is it enhancements that would be recommended to the
    developers of both of the above?

[ Not precisely.  There are very few innovations in the standard,
because it is intended to be a standard.  However, some facilities
will have to be implemented differently on top of existing systems'
facilities to meet the standard.  -mod ]

2)  I would like to keep up with future UNIX enhancements
    (specifically SYS V).  One article in mod.std.unix made
    reference to:
    - a USENIX newsletter - ;login

[ ;login:  The USENIX Association Newsletter is sent free of
charge to all members of the Association.  Their address is
    USENIX Association
    P.O. Box 7
    El Cerrito, CA 94530
    [phone]
    {ucbvax,decvax}!usenix!office

Volume 10, Number 4, October/November 1985 has my article on IEEE 1003.

I am the Institutional Delegate from the USENIX Association to IEEE 1003.

-mod ]

    - a magazine? called UNIX Review

[ The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    [phone]            [phone]

It is my personal opinion that the one on the left is more technical.  -mod ]

    Who do I contact to get on the mailing list or subscribe to
    the above?

[ Some documents frequently referred to by the 1003 committee:

X/OPEN PORTABILITY GUIDE (The Green Book).

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


The System V Interface Definition (The Purple Book)

    To purchase the System V Interface Definition, write to:

        System V Interface Definition
        Select Code 307-127
        AT&T Customer Information Center
        2833 North Franklin Road
        Indianapolis, IN 46219

    Be sure to include the address the document should be shipped to
    and a check or money order made payable to AT&T.

    or call

            1-800-432-6600

    and ask for operator 77. Give the operator the Select Code
    307-127. (You must have a major credit card to order by phone.)

The price is about thirty U.S. dollars.


The /usr/group Standard:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95050

It was $15.00 as of January, 1985.


X3J11 (C Standards Committee):

        Thomas Plum
        Vice Chair, ANSI X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

-mod ]

                Thanks in advance

[ No problem.  If anyone wants other information, let me know.  -mod ]

                Lee Vallone

{ihnp4, mtuxo}!mtsbb!lav

Volume-Number: Volume 6, Number 11

From jsq  Tue Apr  8 17:21:21 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Access to standards-related documents
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
In-Reply-To: <[e-mail]>
Date: 8 Apr 86 23:20:50 GMT
Draft-9: Access.Standards.SVID

From: decwrl!decvax!bellcore!gc49![e-mail] (Randy D. Smith)
Date: Tue, 8 Apr 86 11:55:58 est

In article <[e-mail]> you write:
>    and ask for operator 77. Give the operator the Select Code
>    307-127. (You must have a major credit card to order by phone.)

Looking inside my SVID *Issue 2* I notice that its select code is
320-011 and 320-012.  My catalog agrees with your 307-127 for Issue 1.
I'd recommend people get Issue 2, though.  The numbers I gave are for
the paperback, two volume version.
--
                Randy D. Smith    [phone]
              AT&T Federal Systems, Guilford Center, NC
                    ...!ihnp4!gc49!smithrd


Volume-Number: Volume 6, Number 12

From jsq  Sat Apr 12 18:01:01 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Guest Moderator
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 13 Apr 86 00:00:49 GMT
Draft-9: mod.std.unix

John Chambers of MCC will be guest moderator while I'm in the Europe
for the IEEE 1003 committee meeting in Florence.  Posting may be done
and information may be gotten in the same ways as usual:  John has always
been on the std-unix and std-unix-request aliases.

I hope to repost some of the later articles from the time zone
discussion before I leave since many people seem to want them.
The P1003 committee chair has requested a summary of the whole
discussion.  It doesn't look like I'll have time to do that now
(it's a quarter megabyte of text).  Any volunteers?  :-)

Volume-Number: Volume 6, Number 13

From jbc  Sun May 11 01:23:03 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: another comment on tape file marks
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 May 86 06:22:48 GMT
Draft-9: 10.0


Attached is an article I just sent to net.unix-wizards.  Would the standards
committee be interested in pursuing this?

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


In article <[e-mail]> [e-mail] (Brian Parent) writes:
>I'm having trouble with cpio going to multiple reels.  It seems to
>write to the additional reels fine, but I have yet to successfully
>read the second reel.
>  ..... [An extended description of the problem.  He's doing it right.]

Although there are some bugs in cpio having to do with multiple volumes, this
isn't one of them.  This particular problem happens to be brain damage in the
way Unix tape drivers work, and is also one of my pet peeves, so excuse me for
a moment while I dig out my soapbox.  (BTW, I'll bet that you have some sort
of buffered tape drive, possibly a streamer.  The problem occurs on unbuffered
drives, but it happens much more often on buffered drives.)

The problem is this:  if the tape drive asserts EOT while writing or reading
a record, the driver returns an error.  That's it; that's the whole problem.

The actual senario goes like this:  cpio writes a block that crosses the EOT
marker, so it gets an error back.  (Bug: cpio doesn't close the file at this
point, so there aren't even any EOF marks on the end of tape, either!)  Note
that the block is actually written on the tape.  After you have mounted the
new tape, the block is written \again/ at the beginning of the new reel.  (Also
note that the file is closed at this point, so if you specified a no-rewind tape
device, it puts the EOF markers at the \beginning/ of the new tape before it
starts to write.)  When you read these tapes back, you are depending upon the
fact that reading the block that crosses the EOT will also get the error so
that you swap tapes at exactly the same point.

Well, tain't so.  On unbuffered tape drives, if the EOT mark happens to be in
the inter-record gap, tape drives will differ as to which which block gets the
EOT indication -- it seems to be a matter of timing and I don't understand it.
Sometimes it shows up as getting a duplicated block, and sometimes as a dropped
block.  Different brands of tape drives seem to be somewhat internally
consistant, but you can't even depend upon that.  On a buffered tape drive, the
problem is worse, since the EOT indication is typically given several blocks
\after/ the block that actually writes across the marker; on these drives, it
is not possible to read back the blocks at the end, since the EOT is detected
synchronously on reads.  In any case, the missing or extra block(s) cause a
phase error at some later point.

Now, if you are considering flaming about poor hardware implementations, don't.
The hardware designers have a \standard/ to abide by, and they did so.  That
standard doesn't say that the EOT marker has to be synchronous with the actual
block that caused it, it only says that it has to happen.  It is intended as a
warning that the tape is nearly out; there are still (typically) several tens
of feet left on the tape; that's a lot of room.  Making the reporting of the
EOT only semi-synchronous is a good engineering compromise.  Writing after the
EOT is not an error, but you need to be careful that you don't write a lot --
in fact, almost all standard-compliant implementations routinely write several
blocks past the EOT (due to buffering considerations) before writing the EOV
labels and switching to a new reel.

No, the problem is with Unix's treatment of tape volumes.  Note that as it
stands, Unix cannot even read a multi-volume tape produced on, say, an IBM
system -- several blocks at the end of each reel are simply inaccessible.
And files produced by cpio, where the last block on the tape has no EOF after
it, are difficult to read on an IBM machine, which expects one.

So, what are we to do?  The cure is surprising -- and surprisingly simple:
make Unix comply with the standard.  I don't know why it hasn't been done --
although it would break any existing multi-reel cpio volumes (as far as I know,
that's about the only program that ever creates multi-volume tapes by looking
for an EOT), it won't break any other existing code (or it shouldn't), and new
tapes would be guaranteed to be consistant across all possible machines.  It
shouldn't be any problem to change, since multi-volume tapes don't seem very
common -- notice the dearth of replies to this article since it was posted;
there can't be many people who encounter this problem.

The mods are simple: when writing a tape, if you get an EOT, backspace the
record ("unwrite the record"), write a EOF marker (so you can't read it back),
backspace again (in front of the EOF, so a close (or a shorter write) will
work as expected), and return an error.  If you look closely, this is exactly
what happens if you try to write across the end of a filesystem -- if you try
to cross the boundry on a write, the entire request is rejected (i.e., it is
not turned into a partial write) so that if you follow with a shorter write
that happens to fit, it will succeed.  This actually brings the tape semantics
in closer alignment with that of the disks.

On a read that crosses an EOT marker, you do \nothing/.  You've made sure by
the change above that there should always be an EOF somewhere near the EOT, so
the logic for EOF will keep you from running off the end of the tape.  And now
you can read industry-standard multi-reel tapes.......

I don't expect that this will ever happen.  Unless some statment specificly
requiring this is placed in one of the Unix standards (SVID, /usr/group, or
P1003 (or is it P1006?  Something like that, anyway)), nobody will be motivated
to actually go to the work of modifying the device drivers to fix this.  And
Unix will continue to be a ghetto, at least as far as tape compatibility with
the rest of the world is concerned.......  Are there any standards folks out
there who will accept this gauntlet and prove me wrong?


Volume-Number: Volume 6, Number 14

From jbc  Sun May 11 01:35:40 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: ioctl vs. iocntl (April 3rd draft)
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 May 86 06:35:27 GMT
Draft-9: 7.0

>From allegra!phri![e-mail] Fri May  2 22:44:44 1986
Date: Mon, 28 Apr 86 11:55:42 edt
From: allegra!phri![e-mail] (Roy Smith)

    In section C.3 of the April 3rd draft, it is proposed that ioctl()
be replaced with iocntl().  While I aggree with the basic arguments, I
think iocntl() is a bad name for the new call.

    Somebody once said that your code should pass the telephone test;
if you can't read it to somebody over the phone and have them understand
it, it's too complex.  It has also been said (again I can't remember by
who) [Oh, Kernighan and Plauger, among many others, if you're just looking
for an authority to cite -- mod.] that it is bad style to use variable
names that differ only slightly; using both maxij and maxji for distinct
but similar things is bound to cause confusion when somebody has to read
it later. [Or port code that abuses flexnames, though not a problem here.
-- mod.]

    Surely "ioctl" and "iocntl" fail both these tests of programming
clarity.  I'd like to see the name "iocntl" changed without changing the
proposed functionality.  Perhaps "iofunc" or even "iox".  More descriptive
would be "special_io", but this is bad if you want to appease 7 character
name compilers.

[Any comments from the people to whose hearts "fcntl" may have once been
near and dear? -- mod]

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

Volume-Number: Volume 6, Number 15

From jbc  Sun May 11 01:40:49 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Report from Florence IEEE P1003 meeting
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 May 86 06:40:35 GMT
Draft-9: P1003.IEEE

I am in receipt of a letter from John Quarterman, the official moderator
of this newsgroup, requesting that his report from the IEEE 1003 meeting
in Florence be posted to this newsgroup.

That report, transcribed as accurately as my ability to decipher his
handwriting permits :-), follows herewith:

................
1986 April 23


     The timezone discussion was of  much  interest  to  the
IEEE  1003  committee,  who  would like to include something
appropriate in a Full Use Standard. I delivered  a  copy  of
Volume  5  of mod.std.unix (all 155 pages). To the relief of
the committee, I also included a summary index  that  I  had
done  on  the  plane  over. More details after the following
background.

     There are now several levels  of  documents  associated
with IEEE 1003:

        - Standards (Trial Use / Full Use)
        - Proposed Draft Standards
        - Proposals
        - Requests For Comments (RFCs)
        - Comments

     The latter two categories are new as  of  the  Florence
meeting. Most everything posted in mod.std.unix and remotely
related to IEEE 1003 is now a Comment.

     Some articles may become Requests for Comments  by  the
moderator  obtaining  an  RFC number from the 1003 secretary
(Steve Head) and reposting the article with the  RFC  number
in  the  Subject.  Mark  Horton's  original timezone article
would have  made  an  appropriate  RFC,  for  instance.  The
submitter  can  request  that  an article be an RFC, perhaps
before it is originally posted.

     A proposal is a  formal  request  to  add,  delete,  or
correct  specific  wording  in  the  current  P1003 draft or
standard. Proposal numbers are  assigned  by  the  committee
chair (Jim Isaak).

     Proposals, RFCs, and  Comments  may  come  from  almost
anywhere, by most reasonable written forms of communication.
Proposals and RFCs each  have  serial  numbers  (plus  date,
title,  authors,  section  numbers for the affected areas in
the current draft or  standard,  and  possibly  key  words).
Comments  should  have  all  these  things except for serial
numbers. So please  include  draft  and  section  number  in
subjects of articles submitted to mod.std.unix about P1003.

     Back to timezones .... RFC.001, submitted to  the  IEEE
1003  working  group  in FLorence on 1986 April 18, consists
of:
        - summary of mod.std.unix Vol. 5, by John Quarterman
        - article 65, proposed interface, by Robert Elz
        - timezone examples from article 68 by Arthur Olson
          (just the examples from the last few pages, not all
          of the article)
        - proposal form by John Quarterman

The last item has the same intent as the Elz article but  is
in  a  form which should be as usable as an actual proposal.
It may be submitted as such at the next meeting. So get your
comments  in  before  the  Atlanta USENIX in mid-June if you
want them to affect that particular proposal.

     There was another RFC (from HP) which  solved  all  the
problems  but by a slightly different mechanism. Perhaps its
author would like to post it?


Volume-Number: Volume 6, Number 16

From jbc  Sun May 11 17:51:52 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: iocntl naming
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 May 86 22:51:32 GMT
Draft-9: 7.0

Lest there be others like the anguished soul who took the postscript
to V6#15 to mean that fcntl is *gone* -- no, it's tucked away in S6.5.2.
However, its name seems to have many the same critics as iocntl, and
those comments were solicited. Likewise the defense.



Volume-Number: Volume 6, Number 17

From jbc  Fri May 23 15:28:08 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re:  ioctl vs. iocntl (April 3rd draft)
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 23 May 86 20:27:41 GMT
Draft-9: 7.0

>From rbj@icst-cmr Fri May 16 12:19:42 1986
Date: Thu, 15 May 86 21:08:44 edt
From: Root Boy Jim <rbj@icst-cmr>

        In section C.3 of the April 3rd draft, it is proposed
        that ioctl() be replaced with iocntl().  While I aggree
    with the basic arguments, I think iocntl() is a bad name for
    the new call.

Me too. The abbreviation for `control' is `ctl', not `ctrl', or `cntl'.
If you are going to abbreviate, make it worth while. In the former
case, you have used less than half the letters, in the latter case, more.
The same goes for `address', which people repeatedly abbreviate `addr'
instead of `adr', which will do just as nicely. As a side issue, note
that 99% of all companys have three letter names.

I agree with the rest of the note.

    (Root Boy) Jim Cottrell        <rbj@cmr>
    "One man gathers what another man spills"

Volume-Number: Volume 6, Number 18

From jbc  Fri May 23 15:30:39 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: iocntl naming
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 23 May 86 20:30:24 GMT
Draft-9: 7.0

Date:     Sat, 17 May 86 14:45:31 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>

The name should be "iocontrol" or simply "control".
Why abbrvt whn u dnt hv to?

I see no reason to replace
    int ioctl( int fd, int request, funnyarg )
where "funnyarg" has type (int) or (struct something *)
by anything else, though.

Volume-Number: Volume 6, Number 19

From jbc  Fri May 23 15:39:58 1986
From: [e-mail] (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: POSIX/UNIX Conformance Test Workshop
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 23 May 86 20:39:17 GMT
Draft-9: 1003.3

Date: Thu, 22 May 86 07:23:27 edt
From: cincotta@ICST-SE (Cincotta)
Message-Id: <[e-mail]>

                            Workshop
                               on
  Testing Conformance to the Proposed IEEE P1003/FIPS Standard
                               for
       Portable Operating System for Computer Environments



The Institute for Computer Sciences and Technology (ICST) at  the
National  Bureau  of Standards (NBS) will hold a two-day workshop
on Testing Conformance to Software Standards.  Four  major  topic
areas  will  be addressed: (1) graphics; (2) data management; (3)
office systems/document interchange; and (4) UNIX-derived operat-
ing system environments [UNIX is a trademark of AT&T].

The workshop will be held June 9-10, 1986 at  NBS,  Gaithersburg,
Maryland.

NBS/ICST is considering adopting the  full  use  version  of  the
IEEE/P1003  Standard  for  Portable Operating System for Computer
Environments as a Federal Information Processing Standard (FIPS).
The  IEEE/P1003 standard is intended to provide a vendor indepen-
dent specification for UNIX-derived operating  systems.   It  was
approved  as  a trial use standard by IEEE in March, 1986.  It is
currently being evaluated via the IEEE trial use procedures.

In support of the planned Federal standard, ICST is exploring al-
ternatives for conformance testing.  This workshop is intended to
solicit vendor input on issues relating  to  conformance  testing
for the proposed Federal standard.

Issues to be addressed include:

        - test suite selection

        - test suite availability

        - test suite administration
                - who runs the tests
                - where the tests are run
                - when the tests are run
                - how results are certified

        - test suite maintenance

For more information on the "UNIX" workshop, contact either Roger
Martin or Tony Cincotta at [phone].

For general information and registration, contact Candy Leatherman
at [phone].

Volume-Number: Volume 6, Number 20

From jsq  Fri Jul  4 07:36:21 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-related organizations, standards, and publications
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 4 Jul 86 12:36:03 GMT
Draft-9: Access.User.Groups

This is a rewrite and update of an earlier mod.std.unix article.
Comments are solicited.

Access information is given for the following:
user groups:    USENIX, /usr/group, EUUG
newsletters:    ;login:, commUNIXations, EUUG
standards:    IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
        X3J11 (C language), /usr/group Standard,
        System V Interface Definition, X/OPEN PORTABILITY GUIDE
magazines:    UNIX REVIEW, UNIX/WORLD


A slightly later version of this article will probably appear in
";login:  The USENIX Association Newsletter".  That newsletter is sent
free of charge to all members of the USENIX Association, whose address is

    USENIX Association
    P.O. Box 7
    El Cerrito, CA 94530
    415-528-8649
    {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers.
The next one is in Washington, D.C., 20-23 January 1987.

I am the Institutional Delegate from USENIX to the IEEE 1003 committee
(see below) and one of my functions as such is to get comments from
the USENIX membership and the general public to the committee.
One of the ways I try to do that is by moderating this newsgroup.
I'm also currently on the USENIX Board of Directors.


Another large group related to the UNIX System is /usr/group,

    /usr/group
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95054
    408-986-8840

They publish a newsletter called CommUNIXations.  The May/June 1986
issue contains a report by Heinz Lycklama (the /usr/group Institutional
Delegate to IEEE 1003) on the /usr/group Technical Committee working
groups which met in February 1986 on the areas of Networking,
Internationalization, Graphics, Realtime, Database, Performance,
and the proposed new group on Security.  I will post contact
information for these working groups as taken from that article
in a later mod.std.unix article.

The annual Uniforum Conferences are sponsored by /usr/group
and feature a large trade show.  The next one is in D.C.
at the same time as the next USENIX Conference.  USENIX
and /usr/group have held several concurrent conferences
in the past and will probably do so in the future.


Both USENIX and /usr/group also have tutorials at their
conferences and both sponsor other meeting activities
in addition to their regular conferences.


In Europe there is the European UNIX systems Users Group,
who have a newsletter and hold two conferences a year.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    seismo!mcvax!euug


The IEEE 1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have recently produced the 1003.1 "POSIX" Trial Use Standard.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.  Contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854
        714-821-8380

Ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546 (Book #967).

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Standards Organization (ISO) arena.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Charles River Data Systems
        983 Concord St.
        Framingham, MA 01701
        decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    17-19 September 1986    Palo Alto, CA    hosts: Amdahl, HP and Sun
    9-11 December 1986    Atlantic City NJ with X3J11
    2-6 March 1987        Toronto, ON
        June 1987        Phoenix, AZ    the week of USENIX
        September 1987    New Orleans, LA

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jesperson (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Both will meet concurrently with 1003.1 in Palo Alto in September,
and inquiries should go to the same address as for 1003.1.


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.


X3J11 (C Standards Committee):

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

There is frequent discussion of X3J11 in mod.std.c, which see.


The /usr/group Standard is the principle ancestor of P1003.1:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95050

It was $15.00 as of January, 1985.


The System V Interface Definition (The Purple Book).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

    To purchase the System V Interface Definition, write to:

        System V Interface Definition, Issue 2
        Select Codes 320-011 (Volume 1) and 320-012 (Volume 2)
        AT&T Customer Information Center
        2833 North Franklin Road
        Indianapolis, IN 46219

    Be sure to include the address the document should be shipped to
    and a check or money order made payable to AT&T.

    or call

            1-800-432-6600

    and ask for operator 77. Give the operator the Select Code
    307-127. (You must have a major credit card to order by phone.)

The price is about thirty U.S. dollars.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
(They now have member computer manufacturers from outside Europe.)
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a registered Trademark of AT&T."

Volume-Number: Volume 6, Number 21

From jsq  Mon Jul  7 13:35:25 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Purple Book
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Jul 86 18:34:55 GMT
Draft-9: Access.SVID

Date:     Mon, 7 Jul 86 12:14:36 EDT
From: Dan Franklin <[e-mail]>

Two things about the section on the Purple Book that appeared in the most
recent article.

First, the price is no longer "about 30 dollars".  Doug Gwyn corrected
that.  Here's his message to save scanning the archive:

[ Oops.  Forgot that one; sorry, Doug.  -mod ]

    From: "Moderator, John Quarterman" <[e-mail]>
    Newsgroups: mod.std.unix
    Subject: SVID Issue 2
    Message-Id: <[e-mail]>
    Date: 10 Apr 86 00:24:33 GMT

    From: [e-mail] (Douglas A. Gwyn)
    Date:     Wed, 9 Apr 86 17:55:08 EST

    Select Code 307-127 is supposed to cover both volumes together.
    Total price is something like $52; still $37 a volume I think.
    (Previous SVID owners should have received a discount coupon
    to upgrade to Release 2 for just $37.)

    Volume 1 is essentially equivalent to the whole previous SVID;
    Volume 2 is mostly commands and a few add-ons (e.g. curses).

    Volume-Number: Volume 6, Number 13

As a previous SVID owner, I can confirm that I received a discount
coupon permitting me to upgrade for $37 (and used it).

Second, at the Atlanta USENIX conference the ATT salespeople said they
expected to put out the next issue of the SVID, covering the Release 3
items (streams, networking, etc.) in November or so.  No doubt there
will be a discount again, but if you can borrow a copy until then you
might want to save some money and not order one right away.

    Dan

Volume-Number: Volume 6, Number 22

From jsq  Mon Jul  7 13:55:53 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: improved IEEE 1003.1 mkdir, rmdir for UNIX System V
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Jul 86 18:55:34 GMT
Draft-9: 5.4.2

Doug Gwyn has just posted an implementation of mkdir and rmdir
as defined by IEEE 1003.1 to net.unix (aka [e-mail]).

>From: [e-mail]
>Newsgroups: net.unix
>Subject: improved IEEE 1003.1 mkdir, rmdir for UNIX System V
>Message-ID: <[e-mail]>
>Date: 6 Jul 86 21:38:55 GMT

Volume-Number: Volume 6, Number 23

From jsq  Mon Jul  7 16:41:04 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: P1003.2 Shell Working Group
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Jul 86 21:40:49 GMT
Draft-9: P1003.2.Report

Date: Mon, 7 Jul 86 10:01:08 PDT
From: amdahl![e-mail] (Hal Jespersen)

[ This is the text of an article by a co-chair of the P1003.2 committee
that he wrote for the IEEE TCOS newsletter.  It is in a format which
should be printable on any ASCII terminal or line printer.

The next message will contain the pic source for a related figure.
-mod ]




                       P1003.2 Shell Working Group

                              Hal Jespersen

                            Amdahl Corporation


       A new Working Group has been formed under the sponsorship of
       the Technical Committee on Operating Systems-P1003.2.  It
       has been chartered by the IEEE Standards Board to produce a
       proposed Standard named ``Shell and Utility Application
       Interface for Computer Operating System Environment,'' but
       it is known internally as the ``Shell Group.'' This article
       will discuss the scope and objectives of the new group and
       solicit your participation in its work.

       The Shell Group has generally the same membership as the
       P1003.1 ``POSIXTM'' operating system group and meets as a
       subcommittee-of-the-whole during a portion of P1003.1's
       quarterly meetings.  The group is co-chaired by Hal
       Jespersen of Amdahl Corporation and Don Cragun of Sun
       Microsystems, Inc.

       The purpose of the group is to produce a Standard that will
       complement the basic POSIX operating system Standard by
       providing application programs with an interface to a Shell,
       its command language, and sets of common utility programs.
       It is not intended to specify interfaces that are human
       user-friendly, such as visual shells, desktop metaphors,
       command recall, mice, and so forth.  However, such programs
       will be expected to use the programmatic interfaces provided
       by the Standard.

       The official Scope of the proposed Standard, as approved by
       the Working Group in April, 1986:

                                     SCOPE

              1.  Specify a standard interface that may be accessed
                  in common by both applications programs and user
                  terminal-controlling programs to provide services
                  of a more complex nature than the primitives
                  provided by the 1003.1 Standard.

              2.  The interface will include one or more of the
                  following components:

                    a.  Application program primitives to specify
                        instructions to an implementation-defined
                        ``shell'' facility.

                    b.  A standard command language for a shell
                        that includes program execution, I/O
                        redirection and pipelining, argument







       P1003.2 Shell Working Group                                2



                        handling, variable substitution and
                        expansion, and a series of control
                        constructs similar to other high-level
                        structured programming languages.

                    c.  A recommended command syntax for command
                        naming and argument specification.

                    d.  Primitives to assist applications programs
                        and the shell language in parsing and
                        interpreting command arguments.

                    e.  Recommended environment variables for use
                        by shell scripts and application programs.

                    f.  A minimum directory hierarchy required for
                        the shell and applications.

                    g.  Suites of useful programs or shell
                        functions that may be used for data
                        filtering or manipulation, user environment
                        control, file maintenance, or software
                        development; these suites will be
                        separately implementable.

                    h.  Utilities and standards for the
                        installation of ``add-on'' applications.

              3.  The following is a non-exclusive list of areas
                  outside the scope of the Standard:

                    a.  administrative utilities (privileged,
                        system processes, daemons, etc.)

                    b.  installation or configuration utilities

                    c.  system or file system maintenance utilities

                    d.  networking utilities

                    e.  terminal control or user-interface programs
                        (window managers, etc.)

                    f.  graphics commands

                    g.  text formatting commands

                    h.  data base interfaces (e.g.  SQL, etc.)

             At the same meeting, the Working Group approved the
             following list of Objectives, which will guide the







       P1003.2 Shell Working Group                                3



             Group's work:

                                  OBJECTIVES

              1.  The Standard should be based on the existing
                  facilities and the architectural philosophies of
                  the UNIXr* operating system.

              2.  The Standard will be designed so that it will not
                  automatically exclude other operating systems
                  than those conforming to the 1003.1 Standard.
                  However, the Standard will not be unnecessarily
                  weakened in functionality or style to accommodate
                  other operating systems.

              3.  The Standard will be designed to maximize the
                  conformance and portability of existing UNIX
                  applications.

              4.  The Standard will be designed to maximize its
                  usefulness for international applications.

              5.  Interfaces to the standard shell(s) will be
                  structured so that other shells may be
                  substituted for specific applications.

              6.  The Standard will specify command input and
                  output formats with enough precision to allow
                  those commands to be correctly implemented from
                  the language of the Standard alone.

              7.  The Standard will specify program interfaces in
                  the C language, but will not rule out future
                  specifications in other languages.

             The next meeting will be held in Palo Alto,
             California, at the Hyatt Rickey's Hotel, 09:00-12:00
             Tuesday, September 17, 1986.  An agenda and directions
             to the hotel will be sent out in a future mailing to
             the 1003 mailing list.

             Your participation and support are encouraged.  All
             interested parties are invited to attend the next, and
             all future, meetings.  Proposals for inclusion in the
             Standard, or comments, are accepted from anyone.


       __________

         * UNIX is a registered trademark of AT&T.








       P1003.2 Shell Working Group                                4



             These documents, referred to as ``Requests For
             Comments,'' or RFC's, should be sent (preferably in
             machine-readable and printed form) to:

               Don Cragun
               Sun Microsystems, Inc.
               2550 Garcia Avenue
               Mountain View, CA  94043
               [phone]
               {amdahl|decvax|hplabs|ihnp4|seismo}!sun!dwc

             Information about the Working Group may be obtained
             from Don, or from:

               Hal Jespersen
               Amdahl Corporation
               Mailstop 316
               1250 East Arques Avenue
               Sunnyvale, CA  94088-3470
               [phone]
               {hplabs|ihnp4}!amdahl!hlj


Volume-Number: Volume 6, Number 24

From jsq  Mon Jul  7 16:54:46 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Figure for P1003.2 Shell Working Group
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 7 Jul 86 21:54:30 GMT
Draft-9: P1003.2.Report

Date: Mon, 7 Jul 86 10:01:08 PDT
From: amdahl![e-mail] (Hal Jespersen)

[ This is the source for a figure to accompany the article
in the previous message by Hal Jespersen on P1003.2.
It is in pic format.  You will need pic and troff
or tpic and tex, plus a laser writer, bit mapped monitor,
or other high resolution output device to print it.  -mod ]

.PS
boxht=1.25i
OSI: box "Operating System Interface" " " "IEEE 1003.1" width 6i
     arrow <-> up from 1/6 of the way between OSI.nw and OSI.ne
S:   box "Shell \(**" " " "(Establishes" "Environment)" wid 1.5i
Dat: box "Data" wid .7i ht S.ht/2 with .sw at S.se
Cmd: box "Comm-" "ands" "\(**" wid .7i ht S.ht/2 with .nw at S.ne
     arrow <-> up from 3/4 of the way between OSI.nw and OSI.ne
Ap:  box "Application" wid 1i
API: box "Pro-" "gram" "Inter" "face" "\(**" ht Ap.ht wid .5i \
          with .se at Ap.sw
     arrow <-> from 1/3 of the way between Dat.se and Dat.ne to \
          1/3 of the way between API.sw and API.nw
     arrow <-> from 1/3 of the way between Cmd.se and Cmd.ne to \
      2/3 of the way between API.sw and API.nw
     move up .5i from Ap.t
UIA: box "User" "Interface" "Application" wid 1i
UPI: box "Pro-" "gram" "Inter" "face" "\(**" ht Ap.ht wid .5i \
          with .se at UIA.sw
     arrow <-> from 2/3 of the way between Dat.se and Dat.ne to \
          1/3 of the way between UPI.sw and UPI.nw
     arrow <-> from 2/3 of the way between Cmd.se and Cmd.ne to \
      2/3 of the way between UPI.sw and UPI.nw
     box "Terminal" "Driver" wid 1i ht UIA.ht with .sw at UIA.se
     move up .75i from S.nw
A:   box "\(**" ht .5i wid .5i
     move up .75i from S.t
B:   box "\(**" same
     move up .75i from S.ne
C:   box "\(**" same
     arrow <-> from A.b to 1/4 of the way between S.nw and S.ne
     arrow <-> from B.b to 1/2 of the way between S.nw and S.ne
     arrow <-> from C.b to 3/4 of the way between S.nw and S.ne
     move up .25i from B.t
     "\s+2Utility Program Sets\s0"
.PE

Volume-Number: Volume 6, Number 25

From jsq  Tue Jul  8 07:04:47 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: SVID issues
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 8 Jul 86 12:04:33 GMT
Draft-9: SVID

Date:     Mon, 7 Jul 86 23:48:34 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>

My impression is that the streams/networking SVID volume will
be in addition to the current two volumes, not part of a
replacement for them.

Volume-Number: Volume 6, Number 26

From jsq  Thu Jul 10 05:26:27 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: SVID issues
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 10 Jul 86 10:26:13 GMT
Draft-9: SVID

Date: Thu, 10 Jul 86 01:31:31 PDT
From: ihnp4!meccts!ahby
Organization: MECC Technical Services

>From: Doug Gwyn (VLD/VMB) <[e-mail]>
>My impression is that the streams/networking SVID volume will
>be in addition to the current two volumes, not part of a
>replacement for them.

This is correct.  The Sys Vr3 enhancements will be included in a third
volume to the Purple Book.  This should be available in about
September, although if you are a source licensee, it is apparently
available in draft form today.
Shane P. McCarron            UUCP    ihnp4!meccts!ahby
MECC Technical Services            ATT    [phone]

"Sinners can repent, but stupid is forever."

Volume-Number: Volume 6, Number 27

From jsq  Tue Jul 15 17:10:07 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: public-domain mkdir() implementation
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 15 Jul 86 22:09:35 GMT
Draft-9: 5.4.2

Date:     Thu, 10 Jul 86 7:55:58 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>

Someone has pointed out to me that the mkdir() I posted doesn't
ensure that the directory ends up owned by the effective-UID.
There are technical reasons why this is very difficult; I have
a somewhat improved version (still doesn't work right for EUID
other than real or 0).  It may be possible to completely fix
this on a real UNIX System V, where there is a useful chown(),
but since I don't have one I can't test that.  If there is
sufficient interest I can repost my collection of public-domain
implementations of various new features of the standards.  Send
me your improvements, please.  Thanks.
    - [e-mail]

Volume-Number: Volume 6, Number 28

From jsq  Thu Jul 17 17:47:52 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezones
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 22:46:09 GMT
Draft-9: TZ.RFC.001

This is the first of a series of five articles about timezones.
It is posted to make public previous discussions in this area
and not to stir up the issue again.  The time is propitious because
the U.S. President has just signed a new daylight savings time law.

The other four articles of this series form RFC.001,
which was submitted to the IEEE 1003.1 Working Group in
Florence on 18 April 1986.  The set of articles is as follows:

    V6N29 RFC.001 Timezones:  this article (not part of RFC.001 proper).
    V6N30 RFC.001 Summary of mod.std.unix Volume 5 by the moderator.
    V6N31 RFC.001 Timezone Interface (reposting of V5N65) by Robert Elz.
    V6N32 RFC.001 Timezone Examples (from V5N57) by Arthur Olson.
        (just the examples from the last few pages, not the whole article).
    V6N33 RFC.001 Time Zone Proposal by jsq.

The last item has the same intent as the Elz article but is in a form which
should be usable as an actual proposal.  It may be submitted as such soon.

There was another RFC (from HP) which solved all the same problems but
by a slightly different mechanism.  Perhaps its author would like to post it?

Volume-Number: Volume 6, Number 29

From jsq  Thu Jul 17 17:55:16 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Summary of mod.std.unix Volume 5.
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 22:53:24 GMT
Draft-9: TZ.RFC.001

Summary of time zone discussion (and other material) in mod.std.unix Volume 5.
The time zone discussion was in response to a request in P1003 Appendix A.3.
The numbers in parentheses like (N3) correspond to article number within
Volume 5.

The *problem* was first stated by Mark Horton (N3).
    * GMT/local time disparities exist in the real world:
    Internal system time must be GMT (N11) as used by make (N6), etc.
    Many log files are in local time, e.g., RCS, SCCS (N15).
    Users want to see dates displayed in local time (N3).
    Some parameter files are in local time, such as
        UUCP's L.sys (N5), crontab (N13), and at (N69).
    Conversions should work for dates from at least 1 Jan 1970 (N26)
        (for ls, SCCS, RCS, other logs) to near future
        (L.sys, crontab, at) (N65).
    * Network/dialup logistics:
    Synchronization of networked hosts also requires internal GMT (N17).
    Some network-related logs should perhaps be in GMT (N10).
    Users may be in different timezones than hosts (N7, N14, N13).
    Client workstations may be in different time zones than servers (N63).
    * Politics in the real world sets time zones:
    There are many standard one-hour-from GMT timezones (STs);
        some of them may have different names in different countries.
    There are many Dalight Savings Times (DSTs) related to STs,
        usually by adding one hour.
        These DSTs differ even within the same ST (N63).
        Double daylight savings time is sometimes used (N62, N58).
        Even daylight losing time is plausible (N51, N65).
    Sometimes the DST offset from ST is not integral hours (N28).
    There are local times which are not DSTs
        and also not integral hours from GMT (N19, N13).
    Offset precision of minutes is necessary (N19) but seconds not (N63).
    ST may change at any time (China switching to several zones, N62).
    DST may change at any time and with little notice (Australia, N65).
        or for brief periods (U.S. presidential elections, N27).
    Timezone names may conflict (Bering Strait Time/British Summer Time)
        or be non-alphabetic (N54, N48).

Some *deficiencies* of existing implementations (N3).
    * V7/BSD: inefficiency of system call.
    * System III/V: initialization and security (N3, N66, N63, N4, N50);
    one hour precision is not enough (N63).
    * both: DST tables wired into kernel or library, respectively.

Proposed *solutions*.
    * Early proposals by Kenneth Almquist (N24) and Bob Devine (N47)
    were very useful for discussion but flawed.
    * Interface as proposed by Robert Elz (N65):
    Three conversions sufficient:  GMT, default local, user's local (N55).
    Timezone format left to the implementation.
    Timezone in environment allowed.
    Default initialization and security provided.
    (A routine to translate timezone name to offset possibly useful (N67).)

Proposed *implementation* by Arthur Olsen (N68,N57) since posted to mod.sources.
    * Inspired Elz's interface and is sufficient for it (N65).
    * Jack Jansen's implementation would also fit Elz's interface (N65).
    * Miscellaneous implementation criteria:
    Should not be shell-specific (N49).
    Should not put timezone offset in u-area (N22, N21, N20).
    Efficiency requirements (N66):
        conversion    of present time fast for logging,
            of near past pretty fast for "ls -l",
            of distant past may be slow.
    * A particular implementation may be broad or narrow,
    depending on the intended market (N65, N63).

Far *future* considerations.
    * Machines are currently considered stationary (N60).
    * Days may not be of 24 hours (N58).
    * Announcement of info-futures list (N59).

Other topics in mod.std.unix Volume 5, with numbers of the
corresponding sections of the IEEE 1003.1 Trial Use Standard:

setuid and environment clearing (N39, N31) 3.1.2.
setuid switching (N46, N45, N44, N43) 4.2.2.
ex-directory (N12, N8)
directory umask 5.3.3, 5.6.1.
    motivation (N35, N23, N22)
    objections (N34, N33, N25)
    proposals to use .cshrc (N30, N35, N29)
    clarifications:  not per cwd (N38); process umask remains (N40)
    philosophy (N42, N37)
    solution (N41)
The IEEE 1003 Committee
    and mod.std.unix (N36, N33, N35)
    Draft 6 (N2)
    meetings:  Denver (N18); Florence (N71).
administrativia (N1, N30).
guest moderator (N71, N70).

End of summary of mod.std.unix Volume 5.

Volume-Number: Volume 6, Number 30

From jsq  Thu Jul 17 18:04:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:03:01 GMT
Draft-9: TZ.RFC.001

[ This is part of RFC.001 and is a reposting of V5N65. -mod ]

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

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 6, Number 31

From jsq  Thu Jul 17 18:08:42 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Examples
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:06:37 GMT
Draft-9: TZ.RFC.001

[ This is part of RFC.001 and is a reposting of some examples from V5N57.
Note that the current version of Arthur Olsen's implementation
is to be found in the mod.sources archives, not in mod.std.unix.
This posting is intended merely to illustrate the variety of
possible timezones.  -mod ]

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 6, Number 32

From jsq  Thu Jul 17 18:11:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: RFC.001 Timezone Proposal
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 17 Jul 86 23:10:14 GMT
Draft-9: TZ.RFC.001

RFC.001 Proposal Form, 18 April 1986, submitted by John S. Quarterman.

Time Zone Proposal based on work by Robert Elz and Arthur Olsen.

Add 4.5.3 and 4.5.4 to the standard and perhaps also
document Arthur Olsen's implementation in an Appendix.

4.5.3    Set Local Time Conversion
Function:  settz()

4.5.3.1    Synopsis
    int settz(p)
    char *p;

4.5.3.2    Description
The settz() function determines the conversion from GMT
of the local times returned by localtime() and ctime().
When called with a null pointer argument (p==0), settz
shall select the appropriate local time conversion for the
location of the host machine on which the call is executed.
When called with a null string (p!=0 && *p=='\0'), settz
shall select no conversion for localtime, making localtime()
and gmtime() equivalent and ctime() and asctime(gmtime())
equivalent.  When called with a non-null string (p!=0 && *p!='\0'),
settz may set the conversion according to that string.
The format of the string and the conversions it may specify
are implementation specific.  If an implementation accepts
non-null string arguments to settz, the implementation
should allow users to define their own conversions
rather than restricting conversions to a standard set.
If settz is called with a string for which the implementation
can not find a conversion, settz shall return -1, but the
conversion it sets is implementation defined and may be one of
GMT, the executing machine's local time, or local time for
the area where the implementation was performed.

4.5.3.3    Returns
Upon successful completion, settz() returns 0, otherwise -1.

4.5.4    Get Local Time
Functions:  localtime(), ctime()

4.5.4.1    Synopsis
[ as in X3J11 ]

4.5.4.2    Description
[ as in X3J11, plus: ]
The local time conversion is specified by a call on settz().
If localtime() or ctime() is called and settz() has not been called
since the last exec(), the localtime() or ctime() call shall call
settz(getenv("TZ")) before performing the local time conversion.
The local time conversion should be accurate for all times
from the base time of the time() function up to the time
the call is made.  Future times should be converted as accurately
as possible with available political information.  Daylight savings
time should be taken into account in both cases.

4.5.4.3    Returns
[as in X3J11 ]

4.5.4.4    Errors
[as in X3J11 ]

Volume-Number: Volume 6, Number 33

From jsq  Sat Jul 19 12:37:44 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
In-Reply-To: <[e-mail]>
Date: 19 Jul 86 17:36:06 GMT
Draft-9: TZ.RFC.001

From: ll-xn!s3sun!sdcsvax!ncr-sd![e-mail]
Date: Fri, 18 Jul 86 15:47:39 PDT
Organization: NCR Corporation, Rancho Bernardo

Some comments about the timezone proposal to be submitted to P1003.
This is mostly nitpicking, but there are some loose ends that such
a proposal will need to specify.  I will comment from Elz's text;
the text of the proposal to P1003 follows this wording closely.

In article <[e-mail]> Robert Elz writes:
>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"));".  ........

Note that this implies that there must be some way for the implementation
to tell (a) if settz has been previously called, and presumably, (b) what
value was provided by settz.  This information should be part of the
interface.  It is easy to imagine a utility logging subroutine that would
want to use the local time when inserting log entries without disturbing
other time-display calculations (the user might be running in a different
time zone), so this logging subroutine will need to be able to set and
potentially reset the time zone information.

[ Perhaps.  The assumption is that a process will either use the
same variety of localtime throughout, or that it will explicitly
set the kind it wants with settz before using localtime.
That still leaves the question of how localtime knows settz
has been used previously, but as long as it does, it's
not clear that an application writer needs to know how
it's done.  -mod ]

>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).

Since I have been bitten too many times by having the default time zone
be that of the implementers, I feel that option three is unreasonable.
Presumably, since an attempt was made to set the time zone to a non-local
value, using GMT as a canonical non-local time zone is probably reasonable
(for everybody except those in England, of course -- perhaps it should be
called UCT when in this mode so as not to use the same abbreviation).

[ This is an example of something you'll find throughout 1003.1:
an attempt to not outlaw existing behavior of existing systems.
If option three were not included (ugly as it is), I doubt the committee
would be able to reach consensus on including settz.  -mod ]

>What's missing:  So far here there is no mention of the "timezone name".
>None of the standard mechanisms is really adequate here.  ......
>Arthur Olson's scheme causes "localtime" to set a global variable
>"tz_abbr" to the correct string name for the timezone just used.

I propose an extension of the System V mechanism.  That interface defines
"extern char *tzname[2]" for the time zone names and has a field in the
tm struct (tm_isdst) that is non-zero if daylight savings is in effect;
i.e., the current timezone name is tzname[tm.tm_isdst != 0].  I propose
that the standard add "extern char *tzname[]" (note that the length is
not specified; the bound would be implementation-defined) and have wording
that says that tzname[tm.tm_isdst] is the name of the relevant timezone.
Since the current System V implementation only sets tm_isdst to zero or
one, this is actually backward compatible.  (In fact, I just looked through
our System V sources for uses of tzname; most of the uses are of the latter
form rather than the former, so this proposal is even more compatible than
it looks.)

>....[problems simulating BSDs "timezone()" function] - 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()  .......

With the above proposal, "timezone()" would return values selected from
the tzname array if the time zone was one covered by the last settz(), or
otherwise return a string of the form "+-hhmm".  This function probably
should not be part of the standard, since it is primarily present for
backward compatibility.  If it is present, it should be depreciated so
that it can go away in the future.

And while we're on backward compatibility, the SysV function tzset() could
be defined as "if(timezone_not_set) settz(getenv("TZ");" to be compatible
with the way it currently works; again, if this function is defined, its
usage should be depreciated.

[ I don't think tzset is in the standard, but that's a useful implementation
note.  -mod ]

System V also defines external variables for the current timezone and daylight
savings rule.  Are there any programs that actually use these?  Should they be
part of the interface as well?  (Or some equivalent functionality?)

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


Volume-Number: Volume 6, Number 34

From jsq  Mon Jul 21 08:46:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
In-Reply-To: <[e-mail]>
Date: 21 Jul 86 13:46:02 GMT
Draft-9: TZ.RFC.001

Date: Mon, 21 Jul 86 01:23:29 edt
From: im4u!caip![e-mail] (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus

>System V also defines external variables for the current timezone and daylight
>savings rule.  Are there any programs that actually use these?  Should they be
>part of the interface as well?  (Or some equivalent functionality?)

Yes, there's an important use.  If you're generating an RFC 822 compatible
>Date: line, you need to know the local offset from GMT or the time zone
name.  You can't just plug in the time zone name, because only the names
in the USA are allowed by 822, and if you try to extend that to the rest
of the world, you run into ambiguities.  In general, you can't assume that
someone in an arbitrary location in the world will understand your local
name for your time zone.  So you have to generate a zone like "+hhmm".

One might even claim that, in a zone like Japan, asking for the time zone
name should return "+0900" rather than "JST".  Probably not, but it's
a thought.

    Mark

Volume-Number: Volume 6, Number 35

From jsq  Tue Jul 22 20:01:34 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: RFC.001 Timezone Interface
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 23 Jul 86 01:00:55 GMT
Draft-9: TZ.RFC.001

Date: 23 Jul 86 08:38:34 +1000 (Wed)
From: Robert Elz <munnari![e-mail]>

I have (more than) a few comments about some comments
about the timezone proposal.

[ There's only one comment from the moderator in this article:
discussions are very useful, but to get in the standard it needs
exact wording.  In other words, anyone wanting changes to the
proposal form I posted should supply *exact wording changes*.
(An alternative would be to submit a complete new proposal.)
-mod ]

Quotes until stated otherwise are from Greg Noel (ncr-sd!greg)...

> Note that this implies that there must be some way for the implementation
> to tell (a) if settz has been previously called, and presumably, (b) what
> value was provided by settz.

I agree, I hadn't considered this.  However, its essential that when
there's an interface that sets some static state, there be some means
to determine the current value of that state - I've been frustrated
so many times by hardware with write only registers that I should
have seen this myself.

But, now after thinking about it for a few days, I'm not sure how it
should be done.  There would seem to be two quite different, but
equally possible approaches, though neither is ideal.  One would be
for settz() to save the arg string it is called with, and for a
new function (gettz() ?) to return it.  That sounds simple enough,
but unfortunately might be something of an implementation headache.
The string can be of arbitrary length, so no static buffer in settz
to hold it would be appropriate.  That means that settz would be
required to malloc() memory to hold this string, just on the off
chance that it might be needed later (which it very rarely will be).
I really have very limited enthusiasm for making library routines
at this level get involved in storage allocation.  (Settz could
presumably just remember the pointer to the string it was passed,
and gettz could return that pointer - but this has so many potential
problems that its not worth contemplating).

The (an?) other implementation would be to define two functions,
perhaps savetz() and restoretz().  Savetz would return (in some
manner not important here) the internal state that settz has
established.  restoretz() would restablish that state as settz
would have left it.  This might be handled by having savetz
copy the state into a buffer supplied by the caller, or perhaps
it would malloc some memory and return a pointer to that.  Malloc
here is not a problem, as its only being done by the specific
request of the user, its not a hidden side effect.

Of the two schemes, I think I prefer the latter, but I would
appreciate comments from readers, either to the list if you
(and the moderator) think there will be general interest in your
comments, or in mail to me.


I think John Quarterman (our friendly moderator) answered your
query about the "implementors timezone" default possibility
for settz.  I might just add that I can't imagine how a new
implementation could conceivably make that choice - its just
there to cope with old code.  To implement this proposal,
an implementation must be able to obtain both the hosts
local time, and GMT without being told anything externally
(ie: by being handed either (char *)0 or "" resp).  If it
can do that, it can also easily choose one of those as the
default in cases where it is given an invalid argument.


> I propose an extension of the System V mechanism....  I propose
> that the standard add "extern char *tzname[]" ... and have wording
> that says that tzname[tm.tm_isdst] is the name of the relevant timezone.

Yes, this would be nice, unfortunately it can't work.  You are assuming
that there is just one non-DST timezone name, and all the others are
names of various DST types.  This just isn't true in general.
Since tm_isdst must be zero for any tm_* that is not a daylight
savings time representation, your scheme would allow only one
non-DST zone name.  A new field could be added to struct tm to
be the tzname[] index, but this would break all existing code
that wants zone names, and if we're going to do that, perhaps we
should look and see exactly when a zone name is required.

To the best of my knowledge, the only sensible use of a timezone
name is to associate with a human visible date/time representation.
Since these things aren't unique, they are useless to hold any
internal representation of a timezone.  In effect, that means
that the only time a timezone name will (should) ever be needed
is when a date/time has been converted for external output, and
the zone that will be wanted will be the zone of the time that
was just converted.

If anyone has a counter-example, I would be pleased to learn of it.

Given this assumption, it seems that all that's needed is for
localtime() to arrange that the relevant zone name is available
somehow, either in an external "char *" variable, or as the
return value of a function.

For Sys V compatability, and implementation could provide
char *tzname[2] and set both pointers to the zone name
needed?  Is anyone aware of any code this would break?

For v7 conpatability, the timezone(3) function could be made
to ignore its args, and just return the selected zone name.


> And while we're on backward compatibility, the SysV function tzset() could
> be defined as "if(timezone_not_set) settz(getenv("TZ");" to be compatible
> with the way it currently works; again, if this function is defined, its
> usage should be depreciated.

Certainly, AT&T, and anyone who wants to be compatible with current
Sys V programs should provide tzset as indicated, and should make it,
as far as possible (note "tzname" difficulties as mentioned above)
compatible with the functionality of the Sys V tzset.

However, including definitions in the standard, along with wording
like "don't use this, it shouldn't be here, and is going away"
seems ludicrous to me.


> System V also defines external variables for the current timezone and daylight
> savings rule.

I don't know about daylight savings rule, I don't remember that one,
and my Sys V manual seems to have walked away, but "timezone" is
impossible to get right.  There's no doubt that its intended usage
is that tzset() should set this variable to the local standard timezone
offset.  But this assumes that there is such a thing as a "standard
timezone offset" that applies for all times in the zone.  This just
isn't true..  Eg: a couple of years ago now, Singapore (I think)
changed its timezone so it would be the same as Malaysia.  What
value should be put in "timezone" for Singapore?  The correct answer
depends on what time is being converted - if its a time before the
switch, then it should be their old zone, for one after, it should be
the new zone.  That is, its not a constant!


Following quotes are from Mark Horton (cbosgd!mark)...

[about uses of "timezone"]
> Yes, there's an important use.  If you're generating an RFC 822 compatible
> Date: line, you need to know the local offset from GMT...

Nonsense!  This isn't a use of the Sys V "timezone" variable at all.
That's not the information it provides.  What you need for an RFC822
Date: line is the numeric offset of the time that was converted.
That's not necessarily the hosts local time zone (which is what
"timezone" is supposed to contain).  And even in cases where host local
time is what is wanted, "timezone" isn't it - as the local time converted
might have been a daylight savings time.  To turn the Sys V "timezone"
into the correct thing in that case, one would need to imbed some
nonsense like "if (tm->tm_isdst) timezone += 60;"  (or maybe -= 60,
and maybe the number is 3600, details are irrelevant.  And no, I
wouldn't really modify "timezone").  Getting rid of assumptions about
things like DST being one hour forwards is one of the major aims of
all this.

What *is* needed is a method to obtain the timezone offset that is
appropriate for a given time.  That's a different problem entirely.
An interface to provide this information might be valuable.  If
there isn't such an interface, then the offset can easily calculated
in a portable manner by applications (see my posting to mod.sources,
vol 6 issue 12 "datediffs" for an example of doing approximately this).


> One might even claim that, in a zone like Japan, asking for the time zone
> name should return "+0900" rather than "JST".  Probably not, but it's
> a thought.

This was, of course, a joke (and not even a good one).


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

Volume-Number: Volume 6, Number 36

From jsq  Fri Jul 25 10:20:27 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: timezone implementation constraints
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: 1003.1 A.3
Date: 25 Jul 86 15:20:14 GMT
Draft-9: TZ

From: hplabs!hao!vianet![e-mail] (Bob Devine)
Date: Thu, 24 Jul 86 23:13:44 mdt

[ This is really not directly related to IEEE 1003.1, since
it solely discusses the details of an *implementation* and
says nothing about the *interface*.  However, it does
address something which has been previously discussed
in this newsgroup, and I can't think of a better place for it.
However, please do detailed line-by-line discussions of this
through mail among interested parties.

Could we find a new topic?
-mod]

  Arthur Olson's recent posting to mod.sources included the updated
settz data tables.  This reply in mod.std.unix is to correct some
of the entries in the table and re-raise my points about what is the
best implementation.  I believe everyone has agreed on Robert Elz's
direction for the POSIX document wording.

  The lines beginning with "> " are from Arthur Olson.

> Bob Devine has written that ". . .your table is wrong for MostNA in 1974.
> The correct ending date is 10/27 not 11/24."  Yet on a 4.1bsd VAX/11-750
> system, compiling and executing the program
> [[[ program omitted ]]]
> results in the output
>    Fri Nov  1 22:40:00 1974
>    isdst: 1
> For now we'll stay with 4.1bsd's version.

  The date I gave is correct.  Any version of Unix that uses 11/24 is
simply wrong.  The dates for 1974 and 1975 DST rules are:
      1974   1/6  to 10/27
      1975   2/28 to 10/26
  Even the source for Xenix V that I just checked has it wrong.  Believe
me folks, this comes directly from Dept of Transportation.  (If you are
wondering why DOT has responsibility for such info, drop me a line. BD)

> Note also this from munnari!kre:
> "I recall also being told by someone once that Canada didn't have
> the DST variations in 74/75 that the US did, but I am not nearly
> sure enough of this to add anything."
> If Canada or Mexico decide not to follow the US change in DST that takes
> effect in 1987, additions had best be made below.

Canada did not follow the fuel follies for '4 and '5.
Please split the rules *by country*, not by continent, to avoid such problems.
The "MostNA" rules listed are incorrect for Canada and Mexico!

> Before the Uniform Time Act of 1966 took effect in 1967, observance of
> Daylight Saving Time in the US was by local option, except during wartime.

  This is the acid-test of all proposals for handling DST rules.  When I
submitted my suggestion to mod.std-unix last February (that now seems like
the distant past), I used the most common way of representing the changes.
The reason was I had examined all the world-wide rules and after silently
tearing my hair out trying to come up with a small table, decided to
go with the only way that I had any hope of getting right.  To represent
all of the worldwide rules for just +/- 5 years requires several hundred
lines.  No speed would ever be possible for a full table.  My way was to
just represent the current year.  At best, that simple formula would work
for many years; at worst, changes can't be handled (which is why folks
did fall in love with it).

  The US tried to standardize DST rules in that '66 Act.  But, of course,
there are still many exceptions.  Plus, checking dates prior to it is
painful.  Now imagine how the US was before 1967 and apply that to the
world.  You get the feeling of near chaos?

  I have since come to the conclusion that the best way to represent
DST and timezone information is a single rule plus an "exceptions database".
Only if the simple rule doesn't work (e.g., past or future years, other
timezones) is the database used.  This way, rules can be added as needed.
Or the entire database can be empty with the single rule used for all
conversions.

  DST is almost like the (jeez, I forgot who said it) quote about the
universe "being more complicated that can be possibly imagined".
This is not an exact analogy, but, at least physical laws are controlled
by Congress!


># Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE    LETTER/S
>Rule    MostNA    1967    1973    -    Apr    lastSun    2:00    1:00    D
>Rule    MostNA    1967    1973    -    Oct    lastSun    2:00    0    S

Note: the rules for 1967 - 1973 depend on what state/territory you are in.
For example, Michigan is an exception to the rule for 1969-72 but not for
1967-68.  Eastern Indiana is another tricky one for this period.  Again,
note that this is *after* the '66 Act that tried to standardize DST.

>Rule    MostNA    1974    only    -    Jan    6    2:00    1:00    D
>Rule    MostNA    1974    only    -    Nov    24    2:00    0    S

Should be ====>                         Oct     27

># New names
>Zone    Newfoundland    -3:30    -    NST    # Is DST now observed here?
                        ># If so, when did it start?

Newfoundland observes DST by the same rules as the rest of Canada -- the
last Sunday in April to the last Sunday in October.  It has followed this
pattern since 1951.  Changeover time is 2am.

Saskatchewan is another matter...part in EST; part in CST which doesn't use DST.

># Nonstandard mainland areas:

These rules are impossible to formulate.  The amazing variety of
different DST rules makes such a tabularizing absurd.  The rules vary
by state, by regions within states, by areas that have not yet even
been admitted to the union, by county, by city, and seemingly by whim.

>Rule    SomeUS    1918    1919    -    Mar    lastSun    2:00    1:00    D
>Rule    SomeUS    1918    1919    -    Oct    lastSun    2:00    0    S
>Rule    SomeUS    1942    only    -    Feb    9    2:00    1:00    W # War
>Rule    SomeUS    1945    only    -    Sep    30    2:00    0    S
>
>Zone    East-Indiana    -5:00    SomeUS    E%sT # Usually standard near South Bend
>Zone    Arizona        -7:00    SomeUS    M%sT # Usually standard in Arizona
>
># And then there's Hawaii.
>Rule    Hawaii    1947    only    -    Jun    8    2:00    0    S

The information I have does not show any DST changes in 1947.  DST was
not observed in the period 1946-present.

Bob Devine

Volume-Number: Volume 6, Number 37

From jsq  Sat Jul 26 23:35:50 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: timezone implementation constraints
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 27 Jul 86 04:35:36 GMT
Draft-9: TZ

From: sun!gorodish![e-mail] (Guy Harris)
Date: Sat, 26 Jul 86 17:19:08 PDT

> This is really not directly related to IEEE 1003.1, since
> it solely discusses the details of an *implementation* and
> says nothing about the *interface*.

There is one point, though, that is a concern of the interface; what times
can "localtime" convert and, more generally, what times can a "time_t"
represent?  The P1003.1 standard refers to the definition of "localtime" in
the X3J11 C standard.  That standard doesn't say anything about the meaning
of the value returned by "time".  The P1003.1 standard defines it as UNIX
time, namely the number of seconds since January 1, 1970, 00:00 GMT.

Existing UNIX implementations at least make an attempt to convert times not
in the current year; programs such as "ls" depend on this.  If the current
standard can be interpreted as permitting "localtime", etc. not to make
their best effort to convert times not in the current year, the proposal
must tighten the wording so that this is required.  It may be possible to
permit "best effort" to mean "use this year's rules", although I suspect
people would not be at all happy with such an implementation.  An
implementation must specify what sort of effort it will make to convert
times, so that if somebody doesn't want to get stuck with an implementation
that can't convert times outside the current year they can avoid them.

Obviously, times in the future can't be converted with absolute certainty.
There's not much point in worrying about the inability to predict future
changes to daylight savings time rules.

I suspect all the debates about conversion of times in 1947 may be
completely irrelevant, since the UNIX epoch starts in 1970.  The use of the
word "since" indicates to me that only positive values of a "time_t" are
valid.  Either the standard should require this, or should indicate that
"time_t" may be negative.  I see no reason to permit negative values for
times; the difference *between* times can, however, be negative.  As such,
if "time_t" is to be used in programs for P1003.1 systems to represent the
difference between two times, it should not be an unsigned type.  If one
restricts times (as opposed to time differences) to be positive, the largest
possible differences (both positive and negative) between two times will fit
in a "time_t".

I propose that:

    1) the specification of "time" should be tightened to indicate
       that it will not return a negative value.

    2) the specification of "stat" should also indicate that the
       modification, access, and inode-change times shall never
       be negative.

    3) the "utime" call be required to return EINVAL if an attempt
       is made to set the access or modification times of a file
       to negative values.

If "time" is to return a valid time value, it will never return a negative
value since 1970 has already passed.  Since UNIX came out in 1971, if "stat"
or "fstat" were to return a valid time value for access, modification, or
inode-change time, it will never be negative since there weren't UNIX
systems (or any other flavor of P1003.1-compliant system) before 1970.
Thus, the only way times can be negative are if the system clock is set to a
negative value - since P1003.1 specifies no system call to set the system
clock, this is out of its control, although a caveat about this should
perhaps be included - or if "utime" is used to set the clock to such a
value, which P1003.1 can forbid.

Volume-Number: Volume 6, Number 38

From jsq  Mon Aug 11 09:46:36 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time_t range
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 11 Aug 86 14:46:25 GMT
Draft-9: time_t TZ

From: [e-mail]
Date:     Thu, 7 Aug 86 10:24:40 EDT

I agree that time_t need not be able to represent times before 1970.
However, I think it's rather short-sighted to say that time_t should never
have its high-order bit set.  That restricts it to representing times
before January 2038.  "UNIX will be dead by then!" you say; well, people
have been predicting the death of Fortran and COBOL for a long time now,
and it still hasn't happened, nor does it show any sign of happening.  In
UNIX's case the fact that it's the first portable operating system is
likely to cause it to continue to exist in some form for MANY years.  Even
if UNIX itself doesn't last until 2038, it will certainly last long enough
that application programmers will find it useful to be able to store and
manipulate future time values later than 2038.  They would undoubtedly
appreciate it greatly if the system library routines supplied with UNIX
worked for those time values.

Personally I believe that time_t ought to be an unsigned long, rather than
signed, but that would probably break a lot of existing code.  Still, we
should avoid later problems by specifying that library routines that work
with time_t values should treat it as unsigned, and should work for the
entire range of possible values.  This at least makes it possible for
careful programmers to get their code right.

Most of the time-related facilities in UNIX have long been marked by
an amazing short-sightedness.  Let's not perpetuate it.

    Dan

Volume-Number: Volume 6, Number 39

From jsq  Mon Aug 18 13:23:56 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-Related Organizations and Publications
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 18 Aug 86 18:23:36 GMT
Draft-9: Access.User.Groups

This the latest in a series of similar mod.std.unix articles.
Comments are solicited.

Access information is given for the following:
user groups:    USENIX, /usr/group, EUUG
newsletters:    ;login:, commUNIXations, EUUG
standards:    IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
        X3J11 (C language), /usr/group Standard,
        System V Interface Definition, X/OPEN PORTABILITY GUIDE
magazines:    UNIX REVIEW, UNIX/WORLD


This article will be adapted for ";login:  The USENIX Association Newsletter".
That newsletter is sent free of charge to all members of the USENIX Association,
whose address is

    USENIX Association
    P.O. Box 7
    El Cerrito, CA 94530
    415-528-8649
    {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers.
The next one is in Washington, D.C., 20-23 January 1987.

I (John Quarterman) am the Institutional Delegate from USENIX to the
IEEE 1003 committee (see below) and one of my functions as such is to
get comments from the USENIX membership and the general public to the
committee.  One of the ways I try to do that is by moderating this
newsgroup (currently known as mod.std.unix, eventually as comp.std.unix).
I'm also currently on the USENIX Board of Directors.


Another large group related to the UNIX System is /usr/group,

    /usr/group
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95054
    408-986-8840

They publish a newsletter called CommUNIXations.  The May/June 1986
issue contains a report by Heinz Lycklama (the /usr/group Institutional
Delegate to IEEE 1003) on the /usr/group Technical Committee working
groups which met in February 1986 on the areas of Networking,
Internationalization, Graphics, Realtime, Database, Performance,
and the proposed new group on Security.  I will post contact
information for these working groups as taken from that article
in a later mod.std.unix article.

The annual Uniforum Conferences are sponsored by /usr/group
and feature a large trade show.  The next one is in D.C.
at the same time as the next USENIX Conference.  USENIX
and /usr/group have held several concurrent conferences
in the past and will probably do so in the future.


Both USENIX and /usr/group also have tutorials at their
conferences and both sponsor other meeting activities
in addition to their regular conferences.


In Europe there is the European UNIX systems Users Group.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    seismo!mcvax!euug

They have a newsletter and hold two conferences a year.  The next one is

               EUUG Autumn'1986 Workshop
                      on
               Distributed UNIX Systems

                  Manchester, England
               22nd-25th September, 1986


There are similar groups in other parts of the world, such as Australia,
Japan, and Korea.  If such a group wishes to be included in later versions
of this access list, they should please send me information.


The IEEE 1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have recently produced the 1003.1 "POSIX" Trial Use Standard.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.  Contact:

    IEEE Service Center
    445 Hoes Ln.
    Piscataway, NJ 08854
    714-821-8380

Ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546 (Book #967).

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Standards Organization (ISO) arena.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

    James Isaak
    Chairperson, IEEE/CS P1003
    Charles River Data Systems
    983 Concord St.
    Framingham, MA 01701
    decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    17-19 September 1986    Palo Alto, CA    hosts: Amdahl, HP and Sun
    9-11 December 1986    Atlantic City NJ with X3J11
    2-6 March 1987        Toronto, ON
        June 1987        Phoenix, AZ    the week of USENIX
        September 1987    New Orleans, LA

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jesperson (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Both will meet concurrently with 1003.1 in Palo Alto in September,
and inquiries should go to the same address as for 1003.1.


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

The liaison from X3J11 (sometimes known as the C Standards Committee)
to P1003 is

    Don Kretsch
    AT&T
    190 River Road
    Summit, NJ 07901

A contact for information regarding publications and working groups is

    Thomas Plum
    Vice Chair, X3J11 Committee
    Plum Hall Inc.
    1 Spruce Avenue
    Cardiff, New Jersey 08232

There is frequent discussion of X3J11 in the USENET newsgroup mod.std.c,
which see.  (That newsgroup will eventually be known as comp.std.c.)


The /usr/group Standard is the principle ancestor of P1003.1:

    /usr/group Standards Committee
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95050

It was $15.00 as of January, 1985.


The System V Interface Definition (The Purple Book).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

    System V Interface Definition, Issue 2
    Select Codes 320-011 (Volume 1) and 320-012 (Volume 2)
    or Select Code 307-127 (both volumes).
    AT&T Customer Information Center
    2833 North Franklin Road
    Indianapolis, IN 46219
    1-800-432-6600, operator 77.


The price is about 37 U.S. dollars for each volume or $52 for the pair.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order.  Previous SVID owners should
have received a discount coupon to upgrade to Release 2 for only $37.

Volume 1 is essentially equivalent to the whole previous SVID;
Volume 2 is mostly commands and a few add-ons (e.g. curses).
A third volume is expected in the last quarter of 1986 to cover new
items in System V Release 3, such as streams and networking.  There may
be an upgrade discount similar to the previous one.  A draft copy is
reputed to be available now to source licensees.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
(They now have member computer manufacturers from outside Europe.)
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."

Volume-Number: Volume 6, Number 40

From jsq  Fri Aug 29 13:51:32 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, timezones
Date: 29 Aug 86 18:51:09 GMT
Draft-9: TZ.time_t

From: elsie![e-mail]
Date: Mon, 25 Aug 86 18:35:05 EDT
Subject: negative time_t values

While it's true that no UNIX files date back to before January 1, 1970,
there *are* uses for times before that epoch:  in personnel data bases where
birth dates are recorded; in data bases recording astronomical events;
in stock market price data bases (as used by chartist fanatics); and elsewhere.
(And what of all those old 7094 executables that are being used on IBM machines
running UNIX or a cousin?  :-))

I see more use in the short run for being able to record times between
1901 and 1970 that I see for being able to record times after 2038.
And if we do make it into the twenty-first century, I imagine we'll be working
on machines with 256-bit registers where time_t will have a type that allows
it to represent times into the very distant future; if it's defined properly,
time_t variables will also be able to represent times into the very distant
past.

In summary:  I'd recommend retaining the ability for time_t variables to
represent times before 1970.
--
UNIX is an AT&T registered trademark.
Time is a Time/Life Incorporated trademark.
IBM is an IBM trademark.
--
    UUCP: ..decvax!seismo!elsie!ado   ARPA: elsie![e-mail]
    DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.


Volume-Number: Volume 6, Number 41

From jsq  Wed Sep  3 22:42:17 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 4 Sep 86 03:42:05 GMT
Draft-9: TZ.time_t

From: sun!gorodish![e-mail] (Guy Harris)
Date: Sat, 30 Aug 86 20:39:06 PDT

> While it's true that no UNIX files date back to before January 1, 1970,
> there *are* uses for times before that epoch:

Yes, but there are other representations for such dates and times; there's
no particular need to have "time_t" objects represent dates in 4004 BCE, for
example.  Most of the time, they are represented as mixed-radix numbers,
giving year, month, day, etc., or year, day of year, etc..  The standard
arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are
possible, if slightly less convenient, as are comparisons of dates.  Most of
the examples given don't currently use "time_t", as they're not done on UNIX
systems, and there's no good reason to change them and not much reason to
use "time_t" for future programs of those sorts.  ("time_t" is an especially
poor choice for astronomical event databases; many interesting such events
occurred more than 68 years before 1970....)

> I see more use in the short run for being able to record times between
> 1901 and 1970 that I see for being able to record times after 2038.

Yes, but is there a use for recording UNIX file modification times between
1901 and 1970?  Other times can be recorded in forms other than a "time_t".

> In summary:  I'd recommend retaining the ability for time_t variables to
> represent times before 1970.

It's not a case of "retaining".  The 1003.1 Trial-Use Standard says that the
result of "time" represents "the value of times in seconds *since* 00:00:00
GMT, January 1, 1970" (italics mine), and that the values of the time fields
in a "stat" structure are also times since the epoch.  All definitions of
"since" in the Webster's Third in my office indicate that it refers to times
in the future of the associated event, so March 25, 1967, 18:00:00 GMT is
not a time since the epoch and is not a value that "time" will return, nor
is it a time that will appear in a "struct stat" time field.

Assigning a meaning to negative "time_t" values may be straightforward in
that it's done by replacing "since" with "before, at, or since"; however, it
does involve changes to existing UNIX implementations to permit them to be
interpreted as local times (even with table-driven time zone conversion
routines, one has to get the tables right!).  Few, if any, existing programs
deliberately store negative values in "time_t" variables; many of those
programs are likely to want to store times more than +/- 68 years from the
epoch, so liberalizing the meaning of "time_t" isn't going to help them.
They'll have to wait for the hypothetical time in the future when "time_t"
is made a "long long int" or when all 32-bit machines have been replaced by
64-bit machines to make "time_t" useful to them.

Volume-Number: Volume 6, Number 42

From jsq  Wed Sep  3 23:00:15 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001
Summary: disagree with ado
In-Reply-To: <[e-mail]>
Date: 4 Sep 86 03:59:55 GMT
Draft-9: TZ.time_t

From: hadron![e-mail] (Joseph S. D. Yao)
Date: Tue, 2 Sep 86 04:14:29 edt
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]> you write:
>From: elsie![e-mail]
>While it's true that no UNIX files date back to before January 1, 1970,
>there *are* uses for times before that epoch:  in personnel data bases where
>birth dates are recorded; in data bases recording astronomical events;
>in stock market price data bases (as used by chartist fanatics); and elsewhere.

These should be recorded in the DATE format of your DBMS, not as a
longint!  If your DBMS has no DATE format (tsk!), it should be recorded
as three [or six] ints.  Yes, I know you'll have to compare via a
procedure instead of an op; see the (tsk!) above.

>(And what of all those old 7094 executables that are being used on IBM machines
>running UNIX or a cousin?  :-))

What of them?

>I see more use in the short run for being able to record times between
>1901 and 1970 that I see for being able to record times after 2038.

Possibly.  But I plan to be living (and making plans) well into the
2000's.  I don't want to run up against a wall.  (I already have, in
that versions of Unix today don't allow such dates, and I have -- I
don't remember why! -- tried to use them.)

In addition, you would not be "retaining" any capability -- the systems
I know tend to turn negative dates into something on the order of:
    Sat Feb  5 01:28:16 2^A06
(This is -(60*60*24): the '^A' is, yes, a control-A.)
Any date after 31 Dec 1999 up to some value >> 2^31 loses everything
after the '2' in the year:  I think the second char of the year is
being converted to a control-@, or NUL character.

(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
tried this on the s5/VAX.)
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
            [e-mail] (not yet domainised)

Volume-Number: Volume 6, Number 43

From jsq  Fri Sep  5 17:46:54 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Larry Campbell)
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001
Summary: not all unix libraries are broken
Date: 5 Sep 86 22:46:42 GMT
Draft-9: TZ.time_t

From: [e-mail] (Larry Campbell)
Date: Fri, 5 Sep 86 01:51:09 EDT
Organization: The Boston Software Works, Inc.

>From: hadron![e-mail] (Joseph S. D. Yao)
>
>In addition, you would not be "retaining" any capability -- the systems
>I know tend to turn negative dates into something on the order of:
>    Sat Feb  5 01:28:16 2^A06
> ...
>(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
>tried this on the s5/VAX.)

For what it's worth, I tried several interesting values on my VENIX 2.0
(V7-based) system.  It handles negative values "properly" (that is, it
prints reasonable dates prior to 1970);  for instance, 0xC0000000 yields
"1935 Dec 23 05:22:56".  And it also handles dates beyond 2000 correctly;
0x70000000 yields "2029 Jul 18 01:49:52".
--
Larry Campbell                             The Boston Software Works, Inc.
ARPA: [e-mail]   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     [phone]

[ Depends on what you call broken.

Another example where time values outside the currently supported
(or proposed) range would be useful:  some of us like to play with
genealogical software;  I have known ancestors back to the thirteenth
century and frequently work with data to the sixteenth century.
But time_t probably isn't the appropriate format to keep such dates,
considering Julian vs. Gregorian calendars, old and new style new years,
etc.  -mod ]

Volume-Number: Volume 6, Number 44

From jsq  Sat Sep  6 11:27:03 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Sep 86 16:26:48 GMT
Draft-9: Access.User.Groups

This is the latest in a series of similar mod.std.unix articles.  The
information previously posted in one article has been broken into two:
one about user groups and publications (this one), the other about standards.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG
newsletters:    ;login:, CommUNIXations, EUUG, AUUGN
magazines:    UNIX REVIEW, UNIX/WORLD


USENIX is "The Professional and Technical UNIX(R) Association."

    USENIX Association
    P.O. Box 7
    El Cerrito, CA 94530
    415-528-8649
    {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers.
The next one is in Washington, D.C., 20-23 January 1987.
They publish ";login:  The USENIX Association Newsletter"
which is sent free of charge to all their members.


/usr/group is "the commercially oriented UNIX system users organization."

    /usr/group
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95054
    408-986-8840

They publish a newsletter called CommUNIXations.

The annual Uniforum Conferences are sponsored by /usr/group
and feature a large trade show.  The next one is in D.C.
at the same time as the next USENIX Conference.  USENIX
and /usr/group have held several concurrent conferences
in the past and will probably do so in the future.


Both USENIX and /usr/group also have tutorials at their
conferences and both sponsor other meeting activities
in addition to their regular conferences.


EUUG is the European UNIX systems Users Group.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    seismo!mcvax!euug

They have a newsletter and hold two conferences a year.  The next one is

               EUUG Autumn 1986 Workshop
                      on
               Distributed UNIX Systems

                  Manchester, England
               22nd-25th September, 1986


AUUG is the Australian UNIX systems users Group.

    AUUG
    P.O. Box 366
    Kensington
    N.S.W.    2033
    Australia

    seismo!munnari!auug
    [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each:
the next one will probably be in late February 1986.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.


There are similar groups in other parts of the world, such as Japan and
Korea.  If such a group wishes to be included in later versions of this
access list, they should please send me information.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."

Volume-Number: Volume 6, Number 45

From jsq  Sat Sep  6 11:29:38 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 6 Sep 86 16:29:14 GMT
Draft-9: Access.Standards

This is the latest in a series of similar mod.std.unix articles.  The
information previously posted in one article has been broken into two:
one about user groups and publications, the other about standards (this one).


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on networking, graphics, database,
    internationalization, performance measurements, realtime, and security
X3J11 (C language)
/usr/group Standard
System V Interface Definition
X/OPEN PORTABILITY GUIDE


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have recently produced the 1003.1 "POSIX" Trial Use Standard.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.  Contact:

    IEEE Service Center
    445 Hoes Ln.
    Piscataway, NJ 08854
    714-821-8380

Ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546 (Book #967).

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

    James Isaak
    Chairperson, IEEE/CS P1003
    Charles River Data Systems
    983 Concord St.
    Framingham, MA 01701
    decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    17-19 September 1986    Palo Alto, CA    hosts: Amdahl, HP and Sun
    9-11 December 1986    Atlantic City NJ with X3J11
    2-6 March 1987        Toronto, ON
        June 1987        Phoenix, AZ    the week of USENIX
        September 1987    New Orleans, LA

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Both will meet concurrently with 1003.1 in Palo Alto in September
(though 1003.2 will meet concurrently only on the morning of the 17th),
and inquiries should go to the same address as for 1003.1.

There are two Institutional Representatives to P1003:  John Quarterman
from USENIX and Heinz Lycklama from /usr/group.  As the one from USENIX,
one of my functions is to get comments from the USENIX membership and
the general public to the committee.  One of the ways I try to do that
is by moderating this newsgroup (currently known as mod.std.unix,
eventually as comp.std.unix).  An article related to this one will
appear in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.

The May/June 1986 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in February 1986 on the areas of Networking,
Internationalization, Graphics, Realtime, Database, Performance, and
the proposed new group on Security.  Here is contact information for
those working groups as taken from that article (if you are interested
in starting another working group, contact Heinz Lycklama at the address
below):

/usr/group Working Group on Networking:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

/usr/group Working Group on Internationalization:
    Brian Boyle            Karen Barnes
    Novon Research Group        Hewlett-Packard Co.
    537 Panorama Dr.        19447 Pruneridge Ave.
    San Francisco, CA 94131        M/S 47U2
    [phone]            Cupertino, CA 95014
                    [phone], ext 2438

/usr/group Working Group on Graphics:
    Heinz Lycklama
    Interactive Systems Corp.
    2401 Colorado Ave., 3rd Fl.
    Santa Monica, CA 90404
    [phone]

/usr/group Working Group on Realtime:
    Bill Corwin            Ben Patel
    Intel Corp.            EDS Corp.
    5200 Elam Young Pkwy        P.O. Box 5121
    Hillsboro, OR 97123        23077 Greenfield
    [phone]            Southfield, MI 48075
                    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Celluri            Dave Hinant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton
    Computer Systems Div.
    Gould Inc.
    1101 East University
    Urbana, IL 61801
    [phone]


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

    Don Kretsch
    AT&T
    190 River Road
    Summit, NJ 07901

A contact for information regarding publications and working groups is

    Thomas Plum
    Vice Chair, X3J11 Committee
    Plum Hall Inc.
    1 Spruce Avenue
    Cardiff, New Jersey 08232

There is frequent discussion of X3J11 in the USENET newsgroup mod.std.c,
which see.  (That newsgroup will eventually be known as comp.std.c.)


The /usr/group Standard is the principle ancestor of P1003.1:

    /usr/group Standards Committee
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95050

The price is still $15.00.


The System V Interface Definition (The Purple Book).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

    System V Interface Definition, Issue 2
    Select Codes 320-011 (Volume 1) and 320-012 (Volume 2)
    or Select Code 307-127 (both volumes).
    AT&T Customer Information Center
    2833 North Franklin Road
    Indianapolis, IN 46219
    1-800-432-6600, operator 77.

The price is about 37 U.S. dollars for each volume or $52 for the pair.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order.  Previous SVID owners should
have received a discount coupon to upgrade to Release 2 for only $37.

Volume 1 is essentially equivalent to the whole previous SVID;
Volume 2 is mostly commands and a few add-ons (e.g. curses).
A third volume is expected in the last quarter of 1986 to cover new
items in System V Release 3, such as streams and networking.  There may
be an upgrade discount similar to the previous one.  A draft copy is
reputed to be available now to source licensees.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
(They now have member computer manufacturers from outside Europe.)
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."
Volume-Number: Volume 6, Number 46

From news  Mon Sep 15 09:57:17 1986
From: std-unix%ut-sally.UUCP@sally (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, time zones
Date: 15 Sep 86 14:57:00 GMT
Draft-9: TZ.time_t

From: cbosgd!cbosgd.ATT.COM![e-mail] (Mark Horton)
Date: Wed, 10 Sep 86 12:40:40 edt
Organization: AT&T Bell Laboratories, Columbus

There are many uses for dates, on which you'd like to be able
to do arithmetic.  I don't see where the assumption that time_t
is only useful for file modification times got made.  We have
an application that needs to be able to store birth dates of
people living today, and of their parents.  We would like to be
able to use the same format for parents' birth dates and for
machine generated time stamps.  And we'd like to be able to
easily add or subtract 3 hours, for example, from such a quantity.

Note that all the UNIX routines to deal with dates, such as ctime,
localtime, gmtime, and asctime, deal with time_t quantities.  There
are no operations provided to manipulate a struct tm.  This means
there's a huge penalty for any application that needs to manipulate
times that might be before 1970 or after 2038.  They must implement
a set of primitives to manipulate a struct tm or other data structure
(such as an ISO format time string, which is also broken into year,
month, day, etc.)

Even if you offered us dates back to 1901, it wouldn't be enough for
our application.  We have to go back to about 1850.  But I would hope
to see some facilities added to manipulate a more general date/time
format than a time_t.  Maybe the 4.2BSD struct timeval needs to have
another field added to indicate a base year (defaulting to 1970.)

    Mark

[ There are manipulation (adding, subtracting) routines for timeval
in the 4.2BSD kernel, by the way, though they never seem to have been
brought out into a user-accessible library, even in 4.3BSD (except
for timerisset, timercmp, and timerclear in <sys/time.h>).  -mod ]

Volume-Number: Volume 6, Number 47

From news  Mon Sep 15 11:17:56 1986
From: std-unix%ut-sally.UUCP@sally (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: negative time_t values
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Keywords: RFC.001, time zones
Date: 15 Sep 86 16:17:41 GMT
Draft-9: TZ.time_t

From: mnetor!utzoo!dciem![e-mail]  (Mark Brader)
Date: Thu, 11 Sep 86 18:37:22 edt

> Another example where time values outside the currently supported
> (or proposed) range would be useful:  some of us like to play with
> genealogical software;  I have known ancestors back to the thirteenth
> century and frequently work with data to the sixteenth century.
> But time_t probably isn't the appropriate format to keep such dates,
> considering Julian vs. Gregorian calendars, old and new style new years,

I would say that time_t WOULD be the appropriate format, for PRECISELY
those reason, if the range was available.  To say otherwise is to say
that time_t is inappropriate for the way it's normally used because of
time zones and daylight and standard time.

[ Not precisely, since the form a date is recorded in may vary according
to not only present location but national origin of the recorder or of the
person whose date it is, since there are relatively odd formats (1617/18
is a common format, being used with a date between Jan 1 and Mar 15),
since many dates are incomplete (e.g., only year is known), and since
accuracy to the hour is very rare, not to even mention minutes or seconds.

Incidentally, the Mormon Church is coordinating the development of
something called GEDCOM (GEnealogical Data COMmunications), which is
a genealogical data interchange format.  (It looks rather like a network
presentation layer to me, even resembling XDR a bit.)  They must have
produced some standard for genealogical dates.  I believe I will write
off for a copy for myself.  The address (if anyone else is interested)
is probably

    Genealogical Department
    Ancestral File Operations Unit
    50 E. North Temple St.
    Salt Lake City, UT 84150

However, I suspect that general discussions on genealogy belong in
another newsgroup, so submissions to mod.std.unix related to genealogy
should probably be kept related to date formats or other implementation
issues.  -mod ]

While I'm writing I must correct the common assertion that time_t represents
a time in the UT (GMT) system.  It doesn't.  It represents a time in seconds
from a certain epoch.  The time in time_t form at the moment, for instance, is
526,841,748.  The corresponding time in UT is 4:55:48 pm.  Granted that
the latter is derived from the former by slightly simpler arithmetic than
is my local zone time, that doesn't mean that a time_t represents a time
in UT in particular.

I don't think this is of sufficient interest to post to mod.std.unix,
but you may post any or all if you wish.

Mark Brader, utzoo!dciem!msb
    If ... it seems easier to subvert UNIX systems than most other systems,
    the impression is a false one.  The subversion techniques are the same.
    It is just that it is often easier to write, install, and use programs
    on UNIX systems than on most other systems, and that is why the UNIX
    system was designed in the first place.
                -- Frederick T. Grampp & Robert H. Morris

Volume-Number: Volume 6, Number 48

From news  Mon Sep 15 11:43:23 1986
From: std-unix%ut-sally.UUCP@sally (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: IEEE 1003.1, POSIX and ISO/TC97
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 15 Sep 86 16:42:55 GMT
Draft-9: ISO/TC97

From: genrad!mit-eddie!frog!jim (Jim Isaak)
Date: Tue, 9 Sep 86 10:09:00 EDT

The US technical advisory group (TAG) for ISO/TC97 has agreed to propose
an ISO work item based on the IEEE 1003.1 POSIX effort.  This is the
formal process needed to initiate an ISO standards activity.  This
effort would be CLOSELY coordinated with the 1003.1 effort to assure that
we have a Single Standard.  Individuals and Institutions outside of the
US are encouraged to contact their ISO TC97 representatives and let them
know of their interest, ideally to encourage both an Approval of the
work item; and an agreement to participate in the project.  (Many countries
will be hesitant to participate if they don't know who inside the country
is capable of providing technical input -- so these contacts can aid both
the ISO representatives, and also potentially the individuals who are willing
to participate in their countries "TAGs".)

Volume-Number: Volume 6, Number 49

From news  Mon Sep 15 13:58:20 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 15 Sep 86 18:58:01 GMT
Draft-9: Access.Standards

This is the latest in a series of similar mod.std.unix articles.  The
information previously posted in one article has been broken into two:
one about user groups and publications, the other about standards (this one).
This posting clears up some problems with the IEEE 1003.1 Trial Use Standard
ordering information.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on networking, graphics, database,
    internationalization, performance measurements, realtime, and security
X3J11 (C language)
/usr/group Standard
System V Interface Definition
X/OPEN PORTABILITY GUIDE


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have recently produced the 1003.1 "POSIX" Trial Use Standard.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

    714-821-8380

and ask for Book #967.  Or contact:

    IEEE Service Center
    445 Hoes Ln.
    Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

    James Isaak
    Chairperson, IEEE/CS P1003
    Charles River Data Systems
    983 Concord St.
    Framingham, MA 01701
    decvax!frog!jim

Sufficiently interested parties may join the working group.
The next scheduled meetings of the working group of the committee are

    17-19 September 1986    Palo Alto, CA    hosts: Amdahl, HP and Sun
    9-11 December 1986    Atlantic City NJ with X3J11
    2-6 March 1987        Toronto, ON
        June 1987        Phoenix, AZ    the week of USENIX
        September 1987    New Orleans, LA

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Both will meet concurrently with 1003.1 in Palo Alto in September
(though 1003.2 will meet concurrently only on the morning of the 17th),
and inquiries should go to the same address as for 1003.1.

There are two Institutional Representatives to P1003:  John Quarterman
from USENIX and Heinz Lycklama from /usr/group.  As the one from USENIX,
one of my functions is to get comments from the USENIX membership and
the general public to the committee.  One of the ways I try to do that
is by moderating this newsgroup (currently known as mod.std.unix,
eventually as comp.std.unix).  An article related to this one will
appear in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.

The May/June 1986 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in February 1986 on the areas of Networking,
Internationalization, Graphics, Realtime, Database, Performance, and
the proposed new group on Security.  Here is contact information for
those working groups as taken from that article (if you are interested
in starting another working group, contact Heinz Lycklama at the address
below):

/usr/group Working Group on Networking:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

/usr/group Working Group on Internationalization:
    Brian Boyle            Karen Barnes
    Novon Research Group        Hewlett-Packard Co.
    537 Panorama Dr.        19447 Pruneridge Ave.
    San Francisco, CA 94131        M/S 47U2
    [phone]            Cupertino, CA 95014
                    [phone], ext 2438

/usr/group Working Group on Graphics:
    Heinz Lycklama
    Interactive Systems Corp.
    2401 Colorado Ave., 3rd Fl.
    Santa Monica, CA 90404
    [phone]

/usr/group Working Group on Realtime:
    Bill Corwin            Ben Patel
    Intel Corp.            EDS Corp.
    5200 Elam Young Pkwy        P.O. Box 5121
    Hillsboro, OR 97123        23077 Greenfield
    [phone]            Southfield, MI 48075
                    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Celluri            Dave Hinant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton
    Computer Systems Div.
    Gould Inc.
    1101 East University
    Urbana, IL 61801
    [phone]


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

    Don Kretsch
    AT&T
    190 River Road
    Summit, NJ 07901

A contact for information regarding publications and working groups is

    Thomas Plum
    Vice Chair, X3J11 Committee
    Plum Hall Inc.
    1 Spruce Avenue
    Cardiff, New Jersey 08232

There is frequent discussion of X3J11 in the USENET newsgroup mod.std.c,
which see.  (That newsgroup will eventually be known as comp.std.c.)


The /usr/group Standard is the principle ancestor of P1003.1:

    /usr/group Standards Committee
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95050

The price is still $15.00.


The System V Interface Definition (The Purple Book).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

    System V Interface Definition, Issue 2
    Select Codes 320-011 (Volume 1) and 320-012 (Volume 2)
    or Select Code 307-127 (both volumes).
    AT&T Customer Information Center
    2833 North Franklin Road
    Indianapolis, IN 46219
    1-800-432-6600, operator 77.

The price is about 37 U.S. dollars for each volume or $52 for the pair.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order.  Previous SVID owners should
have received a discount coupon to upgrade to Release 2 for only $37.

Volume 1 is essentially equivalent to the whole previous SVID;
Volume 2 is mostly commands and a few add-ons (e.g. curses).
A third volume is expected in the last quarter of 1986 to cover new
items in System V Release 3, such as streams and networking.  There may
be an upgrade discount similar to the previous one.  A draft copy is
reputed to be available now to source licensees.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

X/OPEN is "A Group of European Computer Manufacturers" who have produced
a document intended to promote the writing of portable facilities.
(They now have member computer manufacturers from outside Europe.)
Their flyer remarks (in five languages), "Now we all speak the same
language in Europe."

The book is published by

    Elsevier Science Publishers
    Book Order Department
    PO Box 211
    1000 AE Amsterdam
    The Netherlands

or, for those in the U.S.A. or Canada:

    Elsevier Science Publishers Co Inc.
    PO Box 1663
    Grand Central Station
    New York, NY 10163

The price is Dfl 275,00 or USD 75.00.  According to the order form,
"This price includes the costs of one update which will be mailed
automatically upon publication."  They take a large number of credit
cards and other forms of payment.


Corrections and additions to this article are solicited.
Oh, yes:  "UNIX is a Registered Trademark of AT&T."
And POSIX is a trademark of IEEE.

Volume-Number: Volume 6, Number 50

From news  Mon Sep 15 14:04:29 1986
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: End of Volume 6
Message-Id: <[e-mail]>
Organization: IEEE 1003 Portable Operating System for Computer Environments Committee
Date: 15 Sep 86 19:04:13 GMT
Draft-9: mod.std.unix

This is the end of Volume 6 of mod.std.unix.  Volume changes are
purely administrative:  this one is so I can print a copy of the
volume to take to the committee meeting this week.  Posting will
resume next week when I return.  Submissions in the meantime will
presumably wait in my mailbox.

Volume-Number: Volume 6, Number 51