what should be in POSIX vs X3J11

seismo!celerity!dreamit!jjw seismo!celerity!dreamit!jjw
Mon May 11 18:55:29 UTC 1987


In response to mail from seismo!nbires!vianet!devine Sat May  9 10:19:15 1987

>   In my last message I proposed dividing the many date/time related
> functions by the rule of 'is it Unix-based or language-based?'. And I
> meant by a call being in Man Section 3 as roughly the same as the latter.

I don't think the division should be based on whether the function is
documented in section 2 or 3 of the Unix manual, that is mostly an artifact
of the Unix implementation.  Instead,  Something should be placed into X3J11
based on whether a standard conforming C program should be able to use the
function.  Something should be placed into the POSIX standard based on
whether all programs running under a conforming operating system should be
able to use the function.

In general I think POSIX should restrict itself to low level functions (such
as "time()") and should avoid specifying higher level functions (such as
"ctime()").  X3J11, however, should specify both low and high level
functions where that makes sense.

Because of the relationship between C and Unix there will be a lot of
overlap between these two and every effort should be made to keep them the
same.  I believe this mailing list is a reasonable place to discuss whether
the various timing functions belong in X3J11, POSIX or both.  It will then
be up to those who are members of the standards committees to bring any
results of such a discussion to the attention of the committees.

I would organize "time" functions as follows:

POSIX only	both		X3J11 only

stime()		time()**	everything else
utime()*	times()
		time_t

The reason for leaving stime() out of X3J11 is that setting a system wide
time and date is not something that is done by many programs and The reason
for leaving utime() out of X3J11 is that the implications of and reasons for
setting file times is likely to be operating systems dependant.  It is also
possible to argue that if programs can read these values they should be able
to set them too.


* file access times (what they are and when they are set) is probably
  outside the purview of this mailing list.

** POSIX should probably have a "gettimeofday" call which provides better
   granularity than seconds.  ftime() has the problem of including timezone
   information which I don't believe belongs in the operating system interface.


				-- J. J. Whelan



More information about the tz mailing list