Ballot # 1

[seismo!nbires!vianet!devine]

Since this is the first ballot, here are the balloting rules:
  1. Send votes by mail to me (uucp address below)
  2. If you feel that the offered choices for an issue are not
     sufficient, send me mail with suggested addition.
     If enough suggestions (or one whose argument is compelling)
     a new round of voting on that issue will be done.
  3. Vote EARLY and only once (even if you are from Chicago).
  4. If a message never got to your mailbox (you can tell by the
     reception of the next higher ballot) I will send another
     to you if it might make a difference in the total vote.
  5. Results are piggybacked on ballots to reduce the number of messages.
  6. Because there are X issues and not X weeks to discuss them,
     there will be several ballots per week.
  7. I will not decide "winning" choices.  I will only keep a count.
  8. Discussion of each ballot in the mailing list is encouraged.
  9. NOTE: Your votes are not the final say on how the Posix document
     is structured but are intended to provide valuable input.  >> How
     best to forward the results is still unknown -- comments please.<<

  If you have any issues you want to see included, please send them to me.

  I am starting out with, what I hope, will be an issue that will not
cause too much argument and gnashing of teeth.

  
Bob Devine
{nbires, hao, ihnp4!stcvax} !vianet!devine

-----------------
  This is Ballot # 1 on Posix time-related issues.

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

-----------------
CURRENT LIST OF ISSUES

1. Fate of the external variables daylight,  timezone, and tzname[]
	[ undecided ]
2. Use the user's environment variable to define the timezone for that user
	[ undecided ]
3. Use the user's environment variable to define timezone rules
	[ undecided ]
4. How user selects a non-default timezone
	[ undecided ]
5. Allow user to define a new timezone and set of rules
	[ undecided ]
6. Definition of what struct tm (or struct new_tm) contains.
	[ undecided ]
7. List of what time functions are needed.
	[ undecided ]
8. Definition of what time_t holds.-- implementation defined or seconds
    since some epoch (eg, 1/1/1970).
	[ undecided ]
9. Drop mktime from standard because of lack of existing art?
	[ undecided ]