ballot 3 -- results

seismo!nbires!vianet!devine seismo!nbires!vianet!devine
Tue Apr 14 00:30:55 UTC 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.
----------------------




More information about the tz mailing list