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. OVERALL: 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 ------------------------- dreamit!jjw-------------- 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 timezone[daylight]; 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. -------------------------