>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...
--------------------------
