what should be in POSIX vs X3J11

[seismo!nbires!vianet!devine]

  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.