- tz - lists.iana.org

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

Re: good news; missing person
by seismo!hadron!jsdy April 13, 1987

April 13, 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. 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: extending the time range
by seismo!cbpavo.MIS.OH.ATT.COM!mark April 13, 1987

April 13, 1987

I don't see 64 bits as a viable alternative; there just aren't any compilers out there that support a 64 bit integer, certainly we can't depend on it, and too much code likes to carry around a single quantity. The more I think about it, the more I think that if I am going to build a general library to handle dates and times, I'm not going to use a time_t as my canonical type, even extended to 64 bits. I need things like variable precision (e.g. my birthday should be clearly precise to the day, not the second, but some measurements have subsecond precision) and the ability to handle notions like "before". I don't see any reasonable way to implement it except using a character string as the canonical format - a char string in ISO format can do it pretty cleanly. Mark

1 0

good news; missing person
by ado April 12, 1987

April 12, 1987

The new time zone stuff and System V time zone stuff behave differently if there's no TZ environment variable. The good news is that this difference is irrelevant, since there's "always" (supposed to be) a TZ environment variable in System V systems. This also means, of course, that other time zone handling schemes are free to do whatever they want if TZ is absent. (Now if I can just remember this until the next time it comes up. . .) Missing person department: mail can no longer be sent to greg(a)nosc.arpa, who's been on the list until now. If anyone has a fully-domainized address for greg, let me know. --ado

1 0

tzsetwall() vs. doing explicit things
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Quick question: doesn't a new question warrant a new Subject: line? We've been going quite a while on these two ... I think that one should use a function specially provided (tzsetwall()) to set the time to "wall clock" time. This could unsetenv("TZ"), or read the "localtime" file for appropriate values of "TZ", or whatever. I like the latter approach, myself ... probably requires unsetenv() and setenv() to do right, though. The point is that we should hide as much of the messy detail as possible inside the time library/module. 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: extending the time range
by seismo!hadron!jsdy April 12, 1987

April 12, 1987

Agreed, there should probably be a new data type (although mark's suggestion tickles my fancy, as a short-range hack). But 64 bits is still limiting. I like an earlier suggestion to use a text- string or a coded decimal string date. 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

TZ changes
by seismo!sun!gorodish!guy April 10, 1987

April 10, 1987

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. I have supplied a diff for localtime.c so that if USG_COMPAT is defined, the value of the global "timezone" variable is forced positive. This is based on observations of Plexus System 3, Xenix System 3, and Xenix System 5. I don't know how USG would treat negative offsets from GMT. Observations presumably not made in Europe. You are correct in that the sign of the "timezone" variable should be positive for time zones such as those in the Western Hemisphere; however, it is not correct to force the offset to be positive, as there are places where the offset simply *isn't* positive (using the UNIX sign conventions). The correct fix is 182c185 < timezone = s.ttis[0].tt_gmtoff; --- > timezone = -s.ttis[0].tt_gmtoff; 197c200 < timezone = ttisp->tt_gmtoff; --- > timezone = -ttisp->tt_gmtoff; or something like that.

1 0

None
by Robert Elz April 10, 1987

April 10, 1987

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), in zones east of Greenwich, "timezone" should in fact be negative (and the application still subtracts its value from the current time). 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! I would also be interested in exactly what application that you have that uses this variable. Does it use it correctly? Simply subtracting it from a time isn't correct, as that won't work in daylight saving times. About all I can think of is that you look at tm_isdst and if that's set compensate by 1 hour (assuming that it is, always, one hour). I don't think the other fixes are appropriate at the minute, but this one will get into a patch posted to mod.sources. Robert Elz

1 0

Re: Reason for DST change in US
by seismo!nbires!vianet!devine April 9, 1987

April 9, 1987

>From uucp Wed Apr 8 17:00 EST 1987 >From hadron!jsdy Wed Apr 8 07:37:44 1987 remote from nbires Received: from hadron.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA00984; Wed, 8 Apr 87 10:21:59 EDT Received: by hadron.UUCP (4.12/4.7) id AA02725; Wed, 8 Apr 87 10:17:34 est Date: Wed, 8 Apr 87 10:17:34 est From: hadron!jsdy (Joseph S. D. Yao) Message-Id: <8704081517.AA02725(a)hadron.UUCP> To: nbires!vianet!devine Subject: Re: Reason for DST change in US Cc: elsie!tz Joe Yao writes: > (*sigh*) That may have been a contribution (nopunintended) to DST > being finally implemented. I know the Farmers' lobby was agin' it. > However, Ben Franklin thought up the idea during one of his ... > ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. > That was a few years before Clorox and Charcoal Briquettes. > > I do notice, however, that your article did not claim that it was > solely done at the behest of Halstead, nor solely for his benefit. > I seem to vaguely recall some other considerations. And that was > definitely not the consideration for its adoption during the War(s), > which was probably what inspired Halstead et al. later on. You misunderstand. I said that the Halstead proposal was just for moving the start of US's DST from the last Sunday in April to the first. I did not write that Halstead was responsible for the invention of the DST idea. His lobbying of Congress occurred about 4 years ago. Here's a thumbnail sketch of how DST came to be: Benjamin Franklin's suggestion for DST was during his tenure as the US ambassador to France (not some junket). His suggestion was ignored. Probably because of the confusion that would have been added to the non-standard timezones then used. However, the true inspiration for DST might have come from a more modern source. An Englishman, William Willet, published a pamphlet in 1907 that called for a seasonal variation in much the same way that Franklin had proposed over a hundred years before him. The first real use of DST came about because of the demands of war. Germany used it during WW I to save electricity. The UK soon followed and many countries did likewise. Most called it "summer time" or "war time". After WW I was over, DST was not observed uniformly across the US because Congress stopped the national observance but many localities kept it anyway. Bob Devine

1 0

Re: Reason for DST change in US
by seismo!hadron!jsdy April 8, 1987

April 8, 1987

> Cost for this recreation windfall was about $50,000 in lobbying costs. (*sigh*) That may have been a contribution (nopunintended) to DST being finally implemented. I know the Farmers' lobby was agin' it. However, Ben Franklin thought up the idea during one of his ... ummm ... voyages ("junkets" is not used in this area ;-)) to Paris. That was a few years before Clorox and Charcoal Briquettes. I do notice, however, that your article did not claim that it was solely done at the behest of Halstead, nor solely for his benefit. I seem to vaguely recall some other considerations. And that was definitely not the consideration for its adoption during the War(s), which was probably what inspired Halstead et al. later on. 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

Reason for DST change in US
by seismo!nbires!vianet!devine April 7, 1987

April 7, 1987

The Associated Press ran a short story this past week on how the change in daylight saving time came to be. The following is not a verbatim transcription but the parts that caught my eye. J. Phillip Halstead was the manager of public affairs at Chlorox Co. and was trying to increase the sales of its Kingsford brand of charcoal briquettes. He found that sales would go up 5-15% for each month that had an extra hour of daylight. He said "More light equaled more barbecues and more charcoal briquettes." Halstead now has a consulting business and estimates that the one hour shift is worth about $4 billion in additional sales for outside- based recreation. Another figure: there will be 4 million additional golf games. Cost for this recreation windfall was about $50,000 in lobbying costs. Bob Devine

1 0

Re: Addition to Arthur Olsen/4.3bsd table-driven ctime
by Steve Summit April 6, 1987

April 6, 1987

>> I cannot be sure that my customers will install the necessary >> timezone support files. > Neither can you be sure that they will install /etc/passwd. You don't > handle that, why handle this? /etc/passwd is standard on the systems I'm selling to; /etc/zoneinfo isn't (yet). A customer doesn't have to install /etc/passwd to get my software to run; I know he already has it, or else he's got a broken system, and it's his problem, not mine. >> I insist that both timezone and DST corrections be applied, even in >> the absence of /etc/zoneinfo, which means that ctime must carry >> some DST information along in its data segment, so it can perform >> at least as well as it used to. > This is unclear to me. What I'm worried about here is systems that haven't applied any fixes. I detest "two steps forward, one step back" improvements, so I'm trying to arrange that a ctime that I link into my code behave 100% backwards-compatibly when shipped to a site that depends on using the old ctime. By "backwards-compatibly," I mean that any new ctime, when operating in an environment without /etc/zoneinfo, must generate the same results as (i.e. localtime must be functionally identical to) the "old" versions of ctime. If not, there will be periods of time (such as the three-week period when lazy and/or sensible systems simply set their clock ahead by an hour) during which the new version of ctime will generate a different local time value than the rest of the utilities on the system (date, ls, anything linked with the old ctime) when presented with the same kernel timestamp. >> The next question is, should any DST information hard-compiled >> into ctime be fixed to reflect recent changes? The surprising >> answer is "no." > That means that your worst case is off by an hour. (Ignoring double > DST.) The same as 4.3's. What am I missing? No. It's off by 0 hours, at all times of any past or present year, when shipped to a system that applies no fixes. (Actually, there is a worse worst case, that of the site that applies the fixes in Article 13, to arrive at a temporarily fixed but still non table-driven ctime. I can't arrange for things to work correctly in this case without breaking things in the other two cases, and I consider the other two cases -- the no fix case and the Arthur Olsen case -- more likely.) Actually, no one else here at Tektronix is at all concerned about this issue, and the witching hour has come and gone, so it's probably not worth our thrashing this out. I thought my arguments were fairly convincing, and I tried to sweeten the pot by offering working code, but I admit that these are pretty fine points I'm considering, and since nobody else seems to be interested, I think I'll drop the whole thing and go off and find other damsels to rescue :-). Steve Summit

2 1

Ballot 3 -- struct tm
by seismo!nbires!vianet!devine April 4, 1987

April 4, 1987

On this ballot feel free to mix'n'match your choices. 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.

1 0

ballot 2 - result
by seismo!nbires!vianet!devine April 4, 1987

April 4, 1987

Here are the opinions on how the time_t type should be defined. It may not have been clear what I was getting at with the questions about "how does your favorite machine arch allow for char addressing" or "how do you measure distances". Those questions were meant to show the analogous nature of time measurement to distance and to how one selects a particular point. Time_t has been a single unit measure -- seconds. Compare that with how address for Intel chips are made -- segment and offset. In that scheme, there can be multiple "names" for the same location that can be resolved only be a normalization process. Two of the choices (e, f and maybe b) were also composed of two parts that, while they do extend the range, may have drawbacks based on their form. Distances can be given in a form that has several units (miles, feet, inches). Calculations are easier if there is only one unit; no conversions are needed. Bob Devine ------------------------------------ 2. The type time_t should be defined as: a. a signed long integer whose value is the number of seconds since 1/1/70 0:0:0 UT (the SVID definition) b. an implementation defined type (a long, or struct, or float or ?) c. a signed long integer whose value is the number of seconds since 1/1/70 0:0:0 UT but whose bits may have a special, overloaded meaning d. an unsigned long whose value is the number of seconds since 1/1/70 0:0:0 UT and extends to the year 2100 e. a signed long integer whose value is the number of seconds from a system- or implementation-selected date and time f. a companion value to a date_t where time_t is number of seconds since the start of the day represented in date_t --Bob Devine---------- Choose 'a'. It is too late for a change to happen. Using an "overloaded meaning" time_t will bite those who are not aware of the circumstances where a particular bit pattern is not a simple count-of-seconds. The other choices could be supported with a library that parallels the functions provided by time() and ctime(3) funcs. ---------------------- --Mark Horton--------- I vote for c', namely an unsigned long integer whose value is the number of seconds since 1/1/70 0:0:0 UT but whose bits may have a special, overloaded meaning Namely: all 1's means "error" anything whose 25th through 32nd least significant bits (e.g. the 8 high bits in a 32 bit long) are all 1 is interpreted instead as follows: take the low order 24 bits The time represents 0:0:0 (or any unspecified time) on the date that many days since 0/0/0, as a signed 24 bit integer Alternatively, "error" might be taken as 9 high order 1's, a day 2^23 days BC. ---------------------- --Arthur David Olson-- A. If any other definition is decided on, the type name must be something other than time_t. Any other approach will break existing code. ---------------------- --Tom Hofmann--------- I vote for 'f' -- with 'f' we get more independent and are on the "safe side". ---------------------- --Geoff Kuenning------ For me, (a) is the clear choice. Only (a) and (d) provide effective compatibility for most programs. (c) is just a way to add complexity to a programmer's life without adding real power; everybody will have to deal with the special bits, but the people who actually care about them will not be saved any code over using a more general time type. This is contrary to the "spirit of UNIX". More practically, it is contrary to the principle of simplicity that has made UNIX so wonderful for programmers. (b) and (e) cost too much in portability of existing programs (although (e) is not as bad as first appears, since most time calculations are in effect relative). (f) provides too many ways to represent the same time, which means that many programs would have to have code to normalize time representations to the same date_t before they could manipulate data, again violating the principle of simplicity. It seems to me that there are really two problems here: time stamping and arithmetic on stamps, and general operations on points in time. The existing time_t is adequate for the first. Making it signed doesn't really help with the general problem, but does make it reasonable to represent time differences using a time_t. Of the other options, only (b) and (f) address the general problem, and they do so poorly and at the expense of simplicity and portability. I'd rather either design a really easy-to-use general mechanism, or just punt the problem and say "if you want more, use a private data structure". Note that a truly general solution is pretty difficult, since it is easy to argue for both picosecond resolution and megayear range. Since a year is about 10**7 seconds, this requires a dynamic range of 10**25, or about 2**84. Floating-point is a pretty good answer, though of course it introduces all of the myriad problems of floating arithmetic. > A. Is the range of 1970 +/- 67 years sufficient? Yes and no. One can infer from the lifetimes of OS/8 and IBM's DOS that there will be UNIX machines in operation well past the year 2038. However, it is quite likely that none of the machines will be 32-bitters by then, so the question may become moot. The negative range, of course, is pretty useless for serious date work, but it seems pretty adequate for time differences. However, since there will be files like /bin/true that will still have a 1980's modification date in the 21st century, the negative range must always be able to handle the difference between the current time and the epoch. > B. What is a 'long' for machines with different architectures? K&R guarantee that a long has at least 32 bits. Time_t should not be required to be a C "long" type; it should simply be required to be at least 32 bits. The wide-word types of the future can use their 32-bit shorts if they want, or they can use a 128-bit long to increase accuracy. > C. How is an invalid time represented? Why is it necessary to represent one? If you decide on a representation, then everybody has to check for it. This is one thing with IEEE floating point, where the check can be done in parallel hardware, and quite another with a software type. In any case, what is the meaning of the term "invalid time"? All times are valid; they just might not be accurate. ----------------------

1 0

Re: Berkeley variant of time zone stuff
by seismo!sun!guy April 2, 1987

April 2, 1987

I'm sorry, but I'm not following this whole discussion. It seems to me that S5 has the problem here; Ultimately, it does, but unless and until AT&T fixes the problem there needs to be some way of getting around it. S5 has no way (does it?) to do so. You can set "TZ" to the "proper" value. S5R3.1, and I think some of the earlier versions, at least on the 3Bs, have a file "/etc/TIMEZONE" that can be used to find the "proper" value. > That's why I suggested the "defaultzone" routine - you need some > portable way of setting the TZ environment variable; given existing > systems, removing it isn't a portable way of forcing local wall clock > time. To make this portable, you'll have to alter S5, right? To make it portable to *all* S5 versions distributed by AT&T, you would, but to make it portable to the later ones, you would just have to have "defaultzone" grab the value from TZ. We can't fix every version of S5, but we can fix some of them. Note that "alter(ing) S5" consist only of adding a file "/etc/TIMEZONE" whose contents are something like "TZ=PST5PDT". You don't have to alter any code, you just have to add "/etc/TIMEZONE" and the "defaultzone" routine - or throw in your own version of "defaultzone" and #ifdef it. (Perfect portability can't always be achieved; I'm willing to force people to use #ifdefs on occasion if that makes the code "more portable" in the sense that you have to change less to make it run elsewhere.) The notion here would be to add "defaultzone" to the P1003.1 or X3J11 standard (whichever one discusses the TZ environment variable - not that the October 1 X3J11 draft does NOT discuss TZ, so unless they're going to add it P1003.1 had better think about picking it up). Systems with rational ways of handling TZ can just return a null pointer or the string "localtime"; systems that insist that you set TZ to something parsable can snarf the default value from some file and return that. Also note that this discussion is directed at vendors as well as users; a vendor can always add "/etc/TIMEZONE" and "defaultzone" to their system if they have to.

1 0