- tz - lists.iana.org

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