Ballot 4 - results (really POSIX / X3J11 relationship)

Robert Elz seismo!munnari!kre
Sat May 2 14:49:13 UTC 1987


    Date:        30 Apr 87 21:32:08 CDT (Thu)
    From:        ahby at meccts.mecc.mn.org (Shane P. McCarron)
    Message-ID:  <8704302132.AA14158 at meccts.MECC.MN.ORG>

    Actually, at the working group meeting last week, we changed the
    definition of POSIX a little bit.
I have always believed that the POSIX working group was comprised
of emminently reasonable and sensible people, and this decision
confirms it.  Unlike X3J11 which seems to have taken off on the
road of innovation, POSIX is very sensibly confining itself to
standardisation.

Please convey my appreciation to the group at the next meeting.

    The unfortunate implication of all this is that strftime and friends
    are not really required by the POSIX standard.
I don't agree that this is unfortunate.  These functions are innovation,
and simply don't belong in POSIX, regardless of how useful they might be.

In fact, its not clear to me that they would belong in POSIX in any case.
Methods of formatting strings for output don't seem to belong in an
operating systems standard.  They do legitimately belong in a language
standard.  I know this whole issue is very much confused by the strong
linage between POSIX and C.  As a test whether something belongs or not,
I would ask a question something like this ... "Would this still be the
natural and proper way to perform the function inother (procedural)
languages?"  If the answer is yes, then the function properly belongs
in POSIX, if no, then it belongs in the language specification.

For example, the functionality of localtime() is to convert a binary
internal time format to a struct containing integers representing
the time.  In Pascal a similar function would be natural (returning
a record).  In Fortran, again it would be natural to use a function
for this purpose (returning an array).  Similarly in Modula, Ada,
Algol, etc.

Strftime() taking a format string, and a struct, and producing
a string containing the formatted time is a perfectly natural C
operation, but isn't the way the operation would usually be expressed
in other languages.  In fact, its doubtful if nost other languages
would have any immediate use for such an operation at all, this
being more commonly performed as an output routine, with the formatted
data appearing only on the external file.

I confine the test to procedural languages, as the interface to POSIX
is a procedural one, testing a proposed function against Smalltalk
is not likely to give useful results.

I think that if POSIX were to attempt to define more than is necessary
for the operating system and its interface (in P1003.1) it will
unnecessarily inhibit any future possibility of creating bindings 
for other languages.

    And since the POSIX Working Group decided at the December meeteing
    to defer to X3 in all things relating to time, the issue is a bit confused.
I think this was a mistake, regardless of the dependance on X3J11.
X3J11 is concerned to make sure that C programs can run in a variety
of environments, not only POSIX.  Because of that there are some things
that they need to leave unspecified.  The representation of times is
one of those, they cannot really even depend on GMT being available.
However, POSIX doesn't have this problem, it can, and should, specify
th details of things such as exactly what a time_t is, and what range
of times must be representable.

So, I would appreciate it if you could suggest to the POSIX group that
they reconsider that December decision, and return the fundamental
operations on times to POSIX.  I believe those to be a definition of
time_t, the function time(), gmtime(), and localtime().  I do not really
believe that asctime() (or ctime()) really belong in POSIX, though pragmatic
considerations might dictate that they be included.  Usage of the
environment variable TZ clearly does belong.  It would be nice
to see (a reasonable definition of) mktime() included, however this
falls into innovation, and should be left to a later revision.

Robert Elz



More information about the tz mailing list