- tz - lists.iana.org

Re: what should be in POSIX vs X3J11
by seismo!sun!guy May 6, 1987

May 6, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. This isn't an adequate definition of a "C library function". "getpwent" is in section 3 of some UNIX manuals, but it is definitely not a C function. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. I wouldn't bet on that. There may have to be some equivalent procedure; Pascal doesn't *have* any date/time manipulation functions. Frankly, I don't think C should have them, either. The standard UNIX library is called the "C library", but this is a misnomer. It contains some functions that may be considered language support for C, some functions that can be considered part of the operating system, and some functions that are really just useful utilities. The Standard I/O library routines are probably best considered to be language support for C (one might also consider them to be part of the operating system, except that the same interfaces have been implemented under other operating systems, and the intent seems to be that all C implementations should have those routines). "open" is clearly part of the operating system, as is "getpwent". "lsearch" is clearly just a utility; the code for "lsearch" could be transplanted to another OS with no trouble (except for possibly writing a "memcpy" routine), and could also be rewritten in any other language that supports the requisite data types. Neither POSIX nor X3J11 includes "lsearch". Although this means that portable code can't use it (or other potentially more interesting utility routines), this is arguably the correct thing to do. However, X3J11 includes some routines that could be considered utility routines or operating system interfaces. The date/time conversion routines fall into these categories: If the format of a "time_t" is considered to be a characteristic of the operating system (since, in most cases, it is the OS that supplies date/time information), "localtime" and "gmtime" are really operating system interfaces. "asctime" is clearly a utility, since it can be expressed in any sufficiently expressive language in an operating-system independent fashion (note that, in fact, a portable implementation of "asctime" is published as part of the current X3J11 draft!). The same is true of "ctime" (for which a portable implementation is also published). "strftime" could also be considered a utility routine, except that it is dependent on the "locale", which is currently considerered part of the C environment. As long as the "locale" is considered part of the C environment, and *not* a part of the operating system, "strftime" should be a part of the C standard. If the ANSI C standard included a definition of low-level routines for obtaining, say, the locale's full name for a month, given a month number of that month, "strftime" could also be written in portable ANSI C and published in the X3J11 draft. It does not include any OS dependencies. I would argue that this sort of "internationalization" belongs neither in an OS standard nor in a language standard; there should be a separate standard which, like e.g. various graphics standards, has bindings for several languages and can be implemented under various OSes. I'm not sure *where* the time-related stuff (i.e., the stuff that deals with "struct tm" values) belongs, although I'd argue in favor of putting it in POSIX. Unfortunately, I don't think the time-related and internationalization stuff is going to be moved out of ANSI C, and I'm also not sure how to split the OS-related and internationalization-environment-related time handling stuff between POSIX and some C-language or other-language binding of an internationalization standard.

1 0

what should be in POSIX vs X3J11
by seismo!nbires!vianet!devine May 5, 1987

May 5, 1987

I believe the way out of this 'who should do it?' problem is to only place those functions that are uniquely OS-related into POSIX. They are 'time()' and 'stime()'. Our task would then be to decide what arguments they take and what errors are defined. X3J11 should deal with the C library functions -- those in section 3 of some Unix manuals. Additional functions can be created within the domain of X3J11 but these should not be required for POSIX. As Robert Elz and others pointed out, POSIX should be the base on which different language environments may run. Imagine how a program would be written using Pascal's date/time manipulation functions. There probably won't be an asctime() call. The difficult part is how to define how the Posix utilities (eg. date, and ls) use and display dates. This is an issue for one of the POSIX subgroups (dot 2?) not the core group. Bob Devine

1 0

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

May 5, 1987

It sounds to me like we're all in agreement: a field in the struct tm defining the offset from GMT is what we need. Whether you call it an "adjustment" or an "offset" is just your point of view. Mark

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 5, 1987

May 5, 1987

> That is why we NEED the tm_tzadj member added to the tm structure. > >I'm not sure I follow how this follows. I agree that a tm_zone >(ie: what zone this time was converted from) is needed, but I >don't see the need for a separate time zone adjustment field. We are agreeing. There is the need for a member (whether the name is tm_zone or tm_adj as it is in HP's implementation) in the tm structure which gives the difference between GMT and localtime in seconds. This applies specifically to the time value in the tm structure. Sorry about any confusion. Ron Tolley

1 0

Re: X3J11
by Robert Elz May 5, 1987

May 5, 1987

Date: Mon, 4 May 87 11:04:30 EDT From: hplabs!hpfcla!hpfclj!hpfcdg!rgt Message-ID: <8705041525.AA23780@hpfcla> That is why we NEED the tm_tzadj member added to the tm structure. I'm not sure I follow how this follows. I agree that a tm_zone (ie: what zone this time was converted from) is needed, but I don't see the need for a separate time zone adjustment field. That is, I can't see anything rational for it to be an adjustment from. I don't believe the concept of a "standard zone" makes any sense, in general there simply is no such thing. The only number of consequence is the offset from gmt of this particular struct tm. kre

1 0

Re: X3J11
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt May 4, 1987

May 4, 1987

> The problem with all this is that mktime is supposed to be the > inverse of localtime, if it was the inverse of gmtime, or if it > had a zone parameter, then this kind of thing could be made to > work. But then mktime would be useless for more common functions, > especially that of hiding the timezone & dst rules from the application. Thank you for stating it so well. That is why we NEED the tm_tzadj member added to the tm structure. Ron Tolley

1 0

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!cbpavo.MIS.OH.ATT.COM!mark May 3, 1987

May 3, 1987

I thought the idea behind POSIX requiring X3J11 was that it eliminated duplication (and possible conflict) between X3J11 and POSIX. If POSIX isn't going to require X3J11, what will they overlay upon? K&R is the only other well known standard, and it's not only incredibly old, but the C library it documents is very incomplete even by 1978 standards. (I have a table I can send out if people are interested.) A lot of stuff was taken out of the /usr/group document because it was already in X3J11; does P.1003 really want to put all that stuff back in? Mark

2 1

Re: Ballot 4 - results (really POSIX / X3J11 relationship)
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

To prevent runaway definitional anarchy, if POSIX includes some C language interface definitions, then oneof(X3J11,POSIX) should defer to the other. I think that POSIX deferring to X3J11 is natural, and should be done unless X3J11 gets really out of hand. Which I don't really think has happened yet. Joe

1 0

Re: Ballot 4 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 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, I should mention that even though X3J11 isn't final, and POSIX is co-operating strongly with (but not subservient to) X3J11, I wish to alter my ballot to support whatever is in X3J11, since it is or will be (it seems) the standard issued first (of the two). 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 - results
by seismo!hadron!jsdy May 3, 1987

May 3, 1987

> POSIX will have strftime and mktime, it isn't an option. X3J11 is still a draft standard: it will go through (I hear tell) at least one more edit-RFC cycle. > Personally, I think strftime botches timezones - "hours" doesn't say > which time zone. Why, nor does ctime() at all, nor System V date. But there is, in the X3J11 strftime(), a %Z for the time zone. [ 10 Oct 1986 ] 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 - 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

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

April 17, 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 14, 1987

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

ballot 3 -- results
by seismo!nbires!vianet!devine April 14, 1987

April 14, 1987

Here are the opinions I received in reply to the 3rd TZ ballot. 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. b. Extend tm structure to contain local timezone offset from UT c. Extend tm structure to contain local seasonal time offset from UT d. Extend tm structure to contain timezone name e. Extend tm structure to contain a pointer to the timezone name f. Drop tm_isdst from the structure. Related questions: 1. If the structure is changed, should it be renamed? 2. What does an invalid structure contain? Can there be invalid struct tm's? 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? 5. How is the structure to be used by the mktime() function. -Bob Devine----------- c, e. Extend tm structure to contain local seasonal time offset from UT, and a pointer to the timezone name. So, struct tm (not renamed) would have two added fields the names of which should be whatever Robert Elz called them to avoid yet-another names. The "local seasonal time offset from UT" is the combination of the base timezone offset from UT and the seasonal offset used locally (aka DST). Combination is calculated according to ISO rules. The "pointer to the timezone name" would be used as a nicety but is not essential. If the pointer is NULL, a tz name can be made from the offset from UT. ---------------------- -Arthur Olson--------- Any of the above is acceptable. I prefer a, as it means the least chance of breaking existing code. If any other course is taken, I'd advocate renaming the struct. > 2. What does an invalid structure contain? Can there be invalid struct tm's? > 3. If the timezone name is included by a char pointer, how does one > make a "permanent" copy of the structure? Need not be defined in the standard. > 4. If the timezone name is included, must there be a standard for timezone > names so that a different process can make sense out of a passed structure? No. If there's a need of this sort, the need should be met with functions provided by the standard. > 5. How is the structure to be used by the mktime() function. I'd advocate that it not be used--that the mktime function be left out of the standard for now because of lack of existing art. We just don't yet know how to do it right. ---------------------- -Mark Horton---------- I vote for b+c smashed together. That is, one field which indicates the amount of time (minutes, seconds, whatever) that the time represented in the struct varies from UT. In effect it's timezone plus the appropriate number of minutes from the daylight flag. I don't care if the DST flag/minutes is also included, but I don't see the need for it. Having b and c both there would be adequate, just slightly less convenient because you'd always have to add them together. I see no need for the name of the time zone, nor for tm_isdst. ---------------------- -sfmag!jgs------------ I vote for: a. As it is defined in the SVID. ---------------------- -Ron Tolley----------- > a. As it is defined in the SVID with no added members. No. This is insufficient to handle all _known_ (Gregorian) time/date values. > b. Extend tm structure to contain local timezone offset from UT No. I assume that this is equivalent to the daylight external variable which DOES NOT change over the period of time. This is far less useful than the value which DOES change with the seasons or with DST. (If my interpretation of "seasonal" to distinguish 'b' and 'c' is incorrect, please give the one that tells about the value in the tm structure. > c. Extend tm structure to contain local seasonal time offset from UT Yes. This will allow the tm structure to contain all of the information that is known about a given time value. By adding/subtracting this value from the time_t equivalent of the tm value, one is GUARANTEED of getting UT. Date(1) MUST make use of this value. Other code should. > d. Extend tm structure to contain timezone name No. > e. Extend tm structure to contain a pointer to the timezone name Yes. Actually adding 'd' or 'e' is more important that which is added. > f. Drop tm_isdst from the structure. Retain only for backwards compatibility. > Related questions: > 1. If the structure is changed, should it be renamed? Please retain the name. There will be a period when the change is made, just as the period we are now in with DST. However this will pass relatively quickly, leaving us with a simple but improved interface. > 2. What does an invalid structure contain? Can there be invalid struct tm's? > 3. If the timezone name is included by a char pointer, how does one > make a "permanent" copy of the structure? The user should be responsible to allocate space for the string with the same lifetime as the space allocated for the tm structure. > 4. If the timezone name is included, must there be a standard for timezone > names so that a different process can make sense out of a passed structure? A null terminated string. This is intended to for human consumption. > 5. How is the structure to be used by the mktime() function. The year, month, day, hour, minute, second, and offset from UT are used to determine the value of time_t to be returned. Then the values of weekday, yearday, isdst, and (potentially) the timezone name are computed. This provides for simple, fast code. For those who wish to compute such things as weekday, there are methods which use two calls to mktime() which can be used. This is however the exception rather than the rule. ---------------------- -dreamit!jjw---------- 3. How should the structure tm be defined? a. As it is defined in the SVID with no added members. Yes b. Extend tm structure to contain local timezone offset from UT Yes c. Extend tm structure to contain local seasonal time offset from UT Yes d. Extend tm structure to contain timezone name Make it an array of applicablre names Yes e. Extend tm structure to contain a pointer to the timezone name NO! f. Drop tm_isdst from the structure. This should be an index into an array of timezone name pointers, Related questions: 1. If the structure is changed, should it be renamed? No, since this structure is built and returned internally to library functions existing programs will not normally be affected if the new fields are just added at the end. 2. What does an invalid structure contain? Can there be invalid struct tm's? No opinion. 3. If the timezone name is included by a char pointer, how does one make a "permanent" copy of the structure? If I understand the question -- the timezone name will either need to be copied separately or will need to remain during additional calls to e.g. localtime. If we retain the tzname array we should be able to guarantee that the name remains in place as long as the timezone is not changed. 4. If the timezone name is included, must there be a standard for timezone names so that a different process can make sense out of a passed structure? I think timezone names are locally standardized to the point that there is no reason to standardize this. ---------------------- -Joe Yao-------------- I'm tempted by conservatism to choose a. However, I'll choose b. and c. both, simply because they really should be packaged there (and not as separate variables, as in #1). Also e., I guess. ----------------------

1 0