April 1987 - tz - lists.iana.org

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