Ballot #1 -- results

seismo!nbires!vianet!devine seismo!nbires!vianet!devine
Fri Mar 27 05:30:40 UTC 1987

Ballot # 1 -- Results

# votes
------- 1. Fate of external variables "daylight",  "timezone", and "tzname[]"
  4   |   a. Don't put in standard and discourage use.
  2   |   b. Don't put in standard and allow implementation-optional use.
  2   |   c. Place in standard as currently defined in SVID.
  2   |   d. Place in standard but with different or expanded definitions.

  Replies for the first round of issues took longer than I anticipated.
Also, I am breaking one of my rules: the results will not be piggybacked
on a following ballot.

  I would guess that everyone was looking at the larger picture than just
this issue, that is, this issue will fall out of the complete design.  The
actual count depends on how I read the emphasis of the explanatory text.

  This ballot might be reissued later when other agreements have been reached.

  Ballot 2 will be sent out tomorrow night (gotta go home now!)

Bob Devine
============================= VOTES ========================================

Bob Devine---------------
Choose 'a'. But I am anticipating how I will vote on "struct tm".
The future of the two are intertwined.  If can't modify tm, change to d.

Arthur Olson-------------
Any of the above outcomes are acceptable to me.
My favorite with regard to daylight and timezone:  a
My favorite with regard to tzname: d

Chris Torek--------------
b.  it should be noted that 4.3BSD does not match SysV,
so mandating SVID breaks existing code, and is insufficent

My vote > d. Place in standard but with different or expanded definitions.
I would like to see a minor extension of the SVID:
	Make "daylight" an index into "tzname" and allow tzname to be
	more than 2 elements long.  This would allow an easy pickup of
	the appropriate name and would also allow for those few cases
	where there are more than one type of daylight savings, e.g
	"double daylight time".

Dennis Mumaugh-----------
Vote: d
Current definition in SVID is chauvinistic and USA oriented.  It
assumes that DST is always one hour offset from standard time and
that it is advanced.  Also one alternate time zone name and one
alternate time zone offset.

Daylight needs to be changed in meaning, timezone needs to be
long timezone[MAXTZ];  offset is derived by 
and tzname needs to be
char *tzname[MAXTZ];

Thus header is

#define MAXTZ 10 	/* maximum possible changes in Time Rules per year */
time_t timezone[MAXTZ] 	/* offset from GMT for each Time Rule */
char *tzname[MAXTZ];	/* name of each Rule */
long daylight;		/* 0 <= daylight < MAXTZ */

Guy Harris---------------
I vote for a. - Don't put in standard and discourage use.
Implementations can provide them if they want, so a. doesn't disallow
implementation-optional use.

I prefer a. to b. and c. because, as they stand, they may not be able to
describe all the wrinkles people can add to their DST rules, and so
I'd prefer to discourage them.

I prefer a. to d. because 1) I prefer not to use global variables if
at all possible and 2) with something like "timelocal" or "mktime",
and the Elz-style fields added to "struct tm", it should not be necessary
for anybody to need direct access to things like "daylight",
"timezone", etc., and the internal data structures used by those
routines should be hidden.

Mark Horton--------------
Either c or d is OK with me; first choice I guess is c unless a better
idea appears.  I think it's important to have the conventions for finding
out the time zone as part of the standard - I have lots of unportable
code because it isn't.

Geoff Kuenning-----------
I vote (c).  If they aren't in the standard, it will break a lot of
existing code when manufacturers drop them.  I don't like it, but we
shouldn't break existing code just because it's ugly.

Ron Tolley---------------
I find it difficult to vote on this issue before some other  issues have
been resolved.  Therefore, I will vote conditionally:

	If the tm structure is changed to provide 1) the difference from
	GMT in seconds  and 2) pointer to a string  which  contains  the
	time zone name,  then vote (a),  otherwise  vote (c).  In either
	case daylight should not be included in the standard.

Shane P. McCarron--------
My response to this question would be b.  We have done this with a
number of other issues - where the wishes of the committee conflict
with reality.  I think that this is something that is so in place that
we cannot simply write it off.  It is interesting to note that the
only place I find a reference to timezone in the X3 document is in
section 4.12, where it says "The local time zone and Daylight Savings
Time are implementation-defined."  POSIX has stated (at the December
meeting) that we will bow to X3 and X/OPEN for specifics about the
timezone stuff.  This looks like the answer right here.

More information about the tz mailing list