Ballot 4 - results

April 28, 1987

      ...
From devine Tue Apr 28 13:30 MDT 1987
To: nbires!seismo!elsie!tz
Subject: Ballot #4 -- results
Cc: devine
Ballot #4 was to say if the following functions should be in Posix.

YES  maybe  NO
---  -----  --
 5           	    time_t     time(time_t*)
 5           	    char*      ctime(time_t*)
 5           	    struct tm* localtime(time_t*)
 5           	    struct tm* gmtime(time_t*)
 5           	    char*      asctime(struct tm*)
 3    1     1	    void       tzset()
 1    1     3	    int        dysize(int)
 1    2     2	    int        strftime(char*, int, char*, struct tm*)
      1     4	    int        strfastime(char*, int, char*, struct tm*)
 3    1     1	    time_t     mktime(struct tm*)

--Bob Devine--------------
yes    time_t     time(time_t*)
yes    char*      ctime(time_t*)
yes    struct tm* localtime(time_t*)
yes    struct tm* gmtime(time_t*)
yes    char*      asctime(struct tm*)
yes    void       tzset()
no     int        dysize(int)
no     int        strftime(char*, int, char*, struct tm*)
no     int        strfastime(char*, int, char*, struct tm*)
yes    time_t     mktime(struct tm*)

 We need a language- and conversion-independent function that converts
a time_t value into a string.  'asctime()' is constrained by the requirement
that its output fit into 26 chars.  It also has the US format hard-coded
into it.  But, I don't think the strf* functions are sufficient.

 On 'mktime': I see a need for it.  However, I am not willing to yet say
"yes" until a working version of the code has been developed.  I'll write
a version in a month (or so)...
-------------------------- 

--Arthur David Olson------
	YES    time_t     time(time_t*)
	YES    char*      ctime(time_t*)
	YES    struct tm* localtime(time_t*)
	YES    struct tm* gmtime(time_t*)
	YES    char*      asctime(struct tm*)
	YES    void       tzset()
	NO     int        dysize(int)
	NO     int        strftime(char*, int, char*, struct tm*)
	NO     int        strfastime(char*, int, char*, struct tm*)
	NO     time_t     mktime(struct tm*)

Whatever package is eventually standardized should be good enough that
dysize isn't needed.

strftime, strfastime, and mktime should not be standardized due to lack of
existing art.
--------------------------

--Ron Tolley--------------
yes    time_t     time(time_t*)
yes    int        stime(time_t*)

yes    char*      ctime(time_t*)
yes    struct tm* localtime(time_t*)
yes    struct tm* gmtime(time_t*)
yes    char*      asctime(struct tm*)

These functions are pretty much expected by everyone to be a part a UN*X
implementation.  If I came upon a system that did not have all of these
functions, it wouldn't be UN*X to me.

yes    int        strftime(char*, int, char*, struct tm*)

POSIX means  "Portable  Operating  Sytem ...".  If  portability
ends at the borders of the U.S.  then we are mistaken.  These  functions
provide  the  ability  to  do   international   dates  and  date  string
formatting.  This is  especially  true  when the two are used  together.
For  example,  in the source for the pr command,  the output of ctime is
dissected to get the date for the page  header.  To print "Apr 17 09:57"
in european languages is tricky enough, but try doing it in Japanese.  I
think that the field descriptors for strftime() are the best that I have
seen,   however  I  could  argue  that  the  similar   nl_cxtime()   and
nl_ascxtime()  from X/OPEN  should be used instead  because of "existing
art".

yes    time_t     mktime(struct tm*)
yes    int        scanftime(struct tm*, int, char*, char*)

These  would  be  welcome  additions.  Until  now  getting  from a  user
specified  date  value  back to a struct  tm* value and from  there to a
time_t  value  has been a black  art.  This  should be  stopped.  I have
actually never seen a proposal for  scanftime()  although I have one for
strtotm() by Tom Osten as Document No.  X3J11/87-215.  Scanftime() would
be the exact inverse of strftime().  It would take a string (char*) with
an expected  format  (char*) of limited  length (less that int) and fill
what it could of the  struct  tm*.  The  number of  characters  actually
parsed  could be  returned  in int.  The  default  would be to leave the
values of unknown struct tm* members alone.  By having a single standard
parsing  routine,  much  of the  black  art of  date  parsing  could  be
eliminated.

yes     int    settz(char*)
yes     int    setlocale(char*)  or nl_init(char *)

All of the routines that have been mentioned so far should be influenced
by two  environment  variables,  TZ and  LANG.  In  particular  ctime(),
localtime(),  and  mktime()  should use the value of the TZ  environment
variable to determine  the timezone  adjustment or offset  between local
time and UT as  appropriate.  (A user  modifiable  table  is  _STRONGLY_
recommended.  The results _MUST_ be uniform.  Etc, etc, etc.)  Similarly
ctime(), asctime(), strftime(), and scanftime() or its equivalent should
use the value of LANG to determine  what the string format, month names,
and other locale-dependent characteristics would be used.  (Again tables
should be used to map LANG values to actual characteristics.)  Note that
to  ease  the  transition  to  using  expecially  the  LANG  environment
variable, settz() called as  settz(getenv("TZ"))  and setlocale() called
as setlocale(getenv("LANG"))  (or the already implemented nl_init() from
X/OPEN)  should  be used.  Also that  setlocale()  will be used for many
other things beside the time oriented functions.

no     int        strfastime(char*, int, char*, struct tm*)

As I recall, this is just a  convenience  for going from a char*  string
all the way to time_t*.  That is not obvious  from this  expression.  In
any case it does not seem necessary.

no     void       tzset()

I have never seen a need to have this at all.  The System V code that I
have seen <comments about V.3 contract go here> always calls tzset()
in localtime() anyway. 

no     int        dysize(int)

I can take this one or leave it.  It is only correct over its entire
range.  The year 1900 was NOT a leap year since it is divisible by
4 and 100 but not 400.  (Check it out using the cal command.)

[...]  instead  of  strftime()  and
mktime(), we could use  nl_ascxtime() and gmtime2() which are in current
X/OPEN systems.  (Gmtime2() is a static routine and does not account for
local time but but is still "existing" art.  I have been tempted to post
it, but I reverse engineered it directly from the AT&T gmtime() code.)
--------------------------

--Joe Yao-----------------
Yes, simply because I have needed them at one or more times in my life:
...
time_t     time(time_t*)
    char*      ctime(time_t*)
    struct tm* localtime(time_t*)
    struct tm* gmtime(time_t*)
    char*      asctime(struct tm*)
    void       tzset()
    int        dysize(int)
    time_t     mktime(struct tm*)
I don't remember what these are supposed to do.  If they are s'posed
to emulate s5/Ultrix date +pattern, I don't think so.  I really think
that a call to localtime() and sprintf() would suffice.  I am quite
willing to be shown wrong.
...
int        strftime(char*, int, char*, struct tm*)
    int        strfastime(char*, int, char*, struct tm*)
--------------------------

--J. J. Whelan------------
From: scubed!sdcsvax!celerity!dreamit!jjw

yes	    time_t     time(time_t*)
yes	    char*      ctime(time_t*)
yes	    struct tm* localtime(time_t*)
yes	    struct tm* gmtime(time_t*)
yes	    char*      asctime(struct tm*)
??	    void       tzset()
??	    int        dysize(int)
??	    int        strftime(char*, int, char*, struct tm*)
??	    int        strfastime(char*, int, char*, struct tm*)
yes	    time_t     mktime(struct tm*)

?? means no opinion	
--------------------------

--Keith Bostic------------
...
time_t     time(time_t*)
    char*      ctime(time_t*)
    struct tm* localtime(time_t*)
    struct tm* gmtime(time_t*)
    char*      asctime(struct tm*)
    void       tzset()
    int        dysize(int)
    int        strftime(char*, int, char*, struct tm*)
    int        strfastime(char*, int, char*, struct tm*)
    time_t     mktime(struct tm*)
I don't know what some of these do, so forgive any ignorance; time() should
be replaced by something that gives you micro-second accuracy a la
gettimeofday.  The timezone stuff should be ripped out of gettimeofday,
though, if it's used.  Dysize() is silly.  You didn't mention it, but if
someone else does, tzsetwall doesn't appear useful.  Harris/Olson/Elz
have probably thought about this more than anyone else...
--------------------------

Ballot 4 - results

seismo!nbires!vianet!devine