what should be in POSIX vs X3J11
seismo!nbires!vianet!devine
seismo!nbires!vianet!devine
Sat May 9 00:30:52 UTC 1987
Unix and C are very tightly interwoven. Trying to separate them
to form two standards is very much a Gordian (Ritchian?) Knot.
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.
This message has more detail. Putting the choices into columns:
Unix-based either-one language-based
time() ftime() asctime()
times() tzset() ctime()
stime() time_t gmtime()
utime() localtime()
difftime()
mktime()
struct tm
X3J11's date formatting functions
Do these groupings make sense? Where should the 'either-one' functions
be placed? Arguments can be made for putting them on both ends of the spectrum.
Here are a couple of examples to show how various vendors with wildly
different OSs dealt with the problem of what to put in their C libraries.
VMS: Base OS has a 64-bit representation of time that is the number of
100 nanoseconds periods since 00:00 on November 17, 1858.
HAS: ctime(), ftime() [but TZ and DST are zero], localtime() [isdst=0]
time() [seconds since 00:00 UT 1/1/70], and times() [the sys fields=0]
MISSING: asctime(), gmtime(), stime(), utime()
DOS: Base OS keeps track of time since 1/1/80
HAS: asctime(), ctime(), difftime(), ftime(), gmtime(), localtime(), tzset(),
time() [returns seconds since 00:00 UT 1/1/70], utime(), and times()
MISSING: stime()
DOS's functions won't give back a formatted string for any time before
1/1/80, ie, long t=12345; ctime(&t) gives back 1/1/80 even though t is
referring to a day in 1970.
More information about the tz
mailing list