- tz - lists.iana.org

Re: Ballot 4 - results
by seismo!meccts.mecc.mn.org!ahby May 2, 1987

May 2, 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. Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. X/OPEN had some reservations about POSIX requiring X3J11, because it would increase the time before there could be conforming systems. Also, a number of people from different implementors felt that when their companies had signed onto the POSIX concept, they had not necessarily bought into X3. These same people also said that they were planning on providing an X3 conforming environment, but not in the same timeframe as POSIX. As a result of these discussions, we redefined the terms CONFORMING APPLICATION and CONFORMING PORTABLE APPLICATION. The new names are PORTABLE APPLICATION USING EXTENSIONS and POSIX CONFORMING <language> APPLICATION. The text of these definitions is: Portable Application Using Extensions A Portable Application Using Extensions shall meet the following requirements: All extensions beyond those permitted to a Posix Conforming Language Application and the corresponding language shall be clearly documented. The application developer documents all application requirements for the operating environment that are implementation dependent including <limits.h> S2.9 characteristics and other related configuration requirements (linear address space, file store requirements, etc.) POSIX Conforming Applications POSIX Conforming Standard C Language Application A POSIX Conforming Standard C Language Application is a strictly conforming program, as defined in the ANSI/X3.159-198x standard, which utilizes only those extensions as described by the service bindings in this standard. In addition, a POSIX Conforming Standard C Language Application shall not depend on any unspecified, undefined, or implementation defined behavior, nor shall it require that any symbolic constant in <limits.h> S2.9 be outside its most restrictive value. As a result of these changes, it is possible to have a Conforming Implementation of POSIX that does not supply an X3 conforming environment. What environment it does provide is unspecified at this time, but the P1003.1 Working Group expects to see something from X/OPEN about a K&R C Language binding, which uses the X/OPEN Portability Guide as the basis for the C Language and its libraries. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. And since the POSIX Working Group decided at the December meeteing to defer to X3 in all things relating to time, the issue is a bit confused. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby(a)MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 Secretary, IEEE P1003.1

2 1

Re: X3J11
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 1, 1987

May 1, 1987

> 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. How? deadline is a time_t (GMT) and so is time(0). Mark

2 1

Re: X3J11
by ado May 1, 1987

May 1, 1987

> > . . .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. > How? deadline is a time_t (GMT) and so is time(0). (I hope I don't end up with egg all over my face on this one!) First, assume that it's 1:30:00 a.m. on a "spring forward" day when we execute the when = *localtime(now); statement. We next do a when.tm_hour += 1; which sets when.tm_hour to 2. We then execute the deadline = mktime(when); statement to answer the question "At what elapsed time in seconds since 1970 will my wall clock read 2:30 a.m.?" Since mktime knows we're springing forward, it returns -1 as a way of saying "There is no such time today." This means that the test in the while (difftime(time(0), deadline) > 0) whatever(); line will *always* succeed--so "whatever" will never be called. (Side questions: does this say anything about whether time_t should be signed? Does it say anything about extra checking difftime should do?) Now assume that it's 1:30:00 a.m. (for the first time :-) on a "fall back" day when we execute the when = *localtime(now); statement. Again we when.tm_hour += 1; deadline = mktime(when); to learn when our local wall clock will read 2:30 a.m. But that won't be until two hours from "now", so the loop will run twice as long as we might expect. --ado

1 0

Re: testing
by seismo!!dlm May 1, 1987

May 1, 1987

Yes, I am there I haven't seen or heard a word from the Time Mailing List in weeks! My mail address is {ihnp4,cbosgd,attunix,cbatt}!cuuxb!dlm. Maybe we're not polling cbosgd or cbatt but I thought so. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

mixed signed/unsigned systems; missing person; archives!?
by ado April 30, 1987

April 30, 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 April 30, 1987

April 30, 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 April 30, 1987

April 30, 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 28, 1987

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

1 0

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

April 28, 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 22, 1987

April 22, 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