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