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