- tz - lists.iana.org

mixed signed/unsigned systems; missing person; archives!?
by ado May 1, 1987

May 1, 1987

A while back I asked for ideas on how to set up time zone information files that could be shared (NFSwise, RFSwise, or otherwise) by machines that used signed time_t values (SVR2, BSD) and machines that used unsigned time_t values (those under Robert Elz's oversight, for example). Thanks to Chris Torek for pointing out the easy fix: limit the years that the file covers so that the only values filed are those for which it doesn't matter whether you interpret them to be signed or unsigned (values from 0 to 0x7fffffff on a VAX). I've added a few lines to the time zone compiler to do this; anyone interested in the lines should let me know. Missing persons department: Francisco Franco is still dead; Dennis Mumaugh is still missing. If you have a new address for either one, let me know. Astonishingly (to me, at least) I got a request for the mailing list "archives" today. So I bundled those letters that I had saved and sent them to the person making the request; I trust that there's not too much missing. And I've arranged for new items to be added to the archive automatically. All of which is a long way of saying that "time zone archives are available." (And of saying that "whenever you join a mailing list being handled by a novice mailing list handler, advise them to keep archives.") -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.CSS.GOV Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Re: Ballot 4 - results
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 1, 1987

May 1, 1987

I was just rereading ANSI C X3J11 and noticed that strftime and mktime are in there. Since POSIX is a superset (by definition) of ANSI C, POSIX will have strftime and mktime, it isn't an option. Personally, I think strftime botches timezones - "hours" doesn't say which time zone. X3J11 says it's OK for gmtime to return NULL at run time if the operating system doesn't keep track of time zones! (Personally I'm a little tired of the timezone nonsense in MS DOS; some programs assume the clock/cal is GMT (those that use Microsoft C) and others local, so I have to set the TZ to EST0EDT to get all programs to work. Mark

1 0

Re: X3J11
by Arthur David Olson May 1, 1987

May 1, 1987

> I was just rereading ANSI C X3J11 and noticed that strftime and mktime > are in there. Since POSIX is a superset (by definition) of ANSI C, > POSIX will have strftime and mktime, it isn't an option. I'm hoping (against hope?) that the descriptions of strftime and mktime will be revised (or dropped from) X3J11. I've attached part of the letter I sent to the committee in early February. --ado > Standard, Page 152, Section 4.12.2.3 > Rationale, Page 95, Section 4.12.2.3 > > Ignoring the coding and grammar errors in the Rationale, > the big problem here is that code like the Rationale's > > when = *localtime(now); > when.tm_hour += 1; > deadline = mktime(when); > > printf("Loop will finish: %s\n", asctime(when)); > while (difftime(time(0), deadline) > 0) whatever(); > > is *not* "a paradigm for continuing some loop for an hour." > The code may continue for two hours (or not at all) > if it is executed just before a daylight saving time transition. > > Since the mktime function does not (and cannot) "replace the > capability to do [arithmetic] which is lost when a programmer cannot > depend on time_t being an integral multiple of some known time unit," > it should be dropped from the Standard (perhaps adding functions > to convert between time_t values and (long?) elapsed seconds since > the epoch--functions that will be extremely useful in converting > "old" software).

1 0

Ballot 4 - results
by seismo!nbires!vianet!devine April 29, 1987

April 29, 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... --------------------------

1 0

ballots stopping for a while
by seismo!nbires!vianet!devine April 29, 1987

April 29, 1987

I won't send out ballot #5 for about a week. I simply don't have the time to do so over the next week and a half. If you have any topics that you want to see sent out in a ballot form, please send them to me. Finally, does anyone have the current mailing address for Dennis Mumaugh? He was last reachable as "dlm(a)cuuxb.ATT.COM". Send the update to Arthur Olson at elsie!tz-request. Bob Devine

1 0

Bad time on init ...
by seismo!hadron!jsdy April 23, 1987

April 23, 1987

> From: seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt > Message-Id: <8704142123.AA05061@hpfcla> > Date: Tue, 14 Apr 87 14:55:55 EST > Subject: Re: good news; missing person > [from me] > >That's what I thought, too. But because people were not setting the > >correct time before coming up multi-user, on a System V Rev 2 V 2.0, > >I put the little rc (bcheckrc?) that sets the date as the last thing > >before a single-user shell, as well as the first thing after. Now I > >get calls that the time is not set properly by this ... I haven't yet > >investigated this properly, but it seems that the TZ is lacking here > >somewhere. [ the exact nature of the problem hadn't come across right, yet. ] > The correct place to set TZ is in init. I have toyed with the idea of > adding a new type of line to inittab which can be used to set TZ in init > so that all of init's children can know about TZ. This was actually n o t the problem. If TZ is not set, the new code just looks at "localtime", and reads that. I should have remembered that, and interpreted the statement of the problem in light of that. The r e a l problem was that when anyone tried to s e t the time (at init or otherwise), it came up 10 hours off! When I finally got this statement of the problem, the actual location of the problem was obvious. You know it, too, when you know that we are in the US Eastern time zone, at -5 hours (+18000 Unix seconds) from GMT: > Date: Sat, 11 Apr 87 08:08:49 +1000 > Message-Id: <12085.545090929@munnari> > From: Robert Elz <seismo!munnari!kre> > Date: Fri, 10 Apr 87 11:52:31 cst > From: ihnp4!infoswx!lan000!rfw > Message-ID: <8704101752.AA13197(a)infoswx.UUCP> > In my experience, the "timezone" variable on USG systems is always > positive -- that is, application code subtracts its value from > the current time, rather than adding it. > This indicates a real bug, though your precise wording is incorrect. > The real problem is that timezone is the opposite sign than it ought > to be, and the fix is simply to negate it (always .. not just when it > would otherwise be negative), ... > Its probably indicative of just how little used this variable is > incidentally, that this bug wasn't noticed before! If there was > ever good evidence to simply kill "timezone" then I think this is it! This is, of course, the problem, since in System V 'timezone' is n o t "little used", but is used all over the place! Date uses it when setting the date. Touch, acctcom, uusub, many SCCS programs, and others (I did a 'find' on a machine far from here) use it. If it should be +5, and it is -5, that gives a 10-hour difference, which is exactly the observed problem. (As observed, it was correct for ISO conventions, but that doesn't cut it with code that assumes the opposite.) All assignments to 'timezone' were converted to negative of what they had been, all those programs (*sigh*) were re-compiled, and everything worked again. Joe Yao jsdy(a)hadron.COM (not yet domainised) hadron!jsdy(a){seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM} {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

1 0

Re: Ballot 4 (functions)
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt April 18, 1987

April 18, 1987

> NO int strftime(char*, int, char*, struct tm*) > NO int strfastime(char*, int, char*, struct tm*) > NO time_t mktime(struct tm*) > >strftime, strfastime, and mktime should not be standardized due to lack of >existing art. As I stated in by response to Bob, the 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.) Ron Tolley

1 0

Colorado time zone
by seismo!nbires!vianet!devine April 17, 1987

April 17, 1987

Yesterday the Colorado House State Affairs Committee voted 7-2 on two resolutions: to move Colorado into the Central zone and to place Colorado in year-round daylight saving time. I believe it is now up to the US Dept of Transportation to decide the result. I don't know if the Governor or state senate must do anything to the resolution. Bob Devine

1 0

Ballot 4 (functions)
by seismo!nbires!vianet!devine April 17, 1987

April 17, 1987

I can't recall if we ever resolved what functions should be in Posix. So, say "yes" or "no" to each of the following functions. Give a rationale (if you want). Add more functions if you believe they are needed. 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*) Bob Devine

1 0

Re: good news; missing person
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt April 15, 1987

April 15, 1987

>> ... there's "always" (supposed to be) a TZ environment >> variable in System V systems. > >That's what I thought, too. But because people were not setting the >correct time before coming up multi-user, on a System V Rev 2 V 2.0, >I put the little rc (bcheckrc?) that sets the date as the last thing >before a single-user shell, as well as the first thing after. Now I >get calls that the time is not set properly by this ... I haven't yet >investigated this properly, but it seems that the TZ is lacking here >somewhere. The correct place to set TZ is in init. I have toyed with the idea of adding a new type of line to inittab which can be used to set TZ in init so that all of init's children can know about TZ. Note however that this will never completely cure the problem, since an application may use some of the flavors of exec() which are designed to drop all environment information. Login uses such a flavor of exec() (at least currently on the system that I am using.) Still, we should be able insure that TZ is defined everywhere in the underlying platform/system on which user applications run. Ron Tolley

1 0