March 1987 - tz - lists.iana.org

Ballot # 1
by seismo!nbires!vianet!devine March 18, 1987

March 18, 1987

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 ]

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!sun!guy March 18, 1987

March 18, 1987

Sometimes we need subsecond precision. Yes, but "time_t"s need not provide subsecond precision; 4.[23]BSD-style "struct timeval" may not be ideal, but they do the job. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Yes, but nothing in a UNIX system happened in the 19th century. Non-UNIX systems lacking "time_t" have done quite well dealing with times; I don't see any need to use "time_t" for every kind of timestamp any application could possibly want. It might be aesthetically "nice" to have the time representation used by the OS be the same that would be used by every conceivable application, but I don't see that it's worth the effort of changing what a "time_t" is. (There are plenty of OSes out there with the same problem; the VMS epoch starts 00:00 - local time, I believe - November 17, 1858.)

1 0

Re: List of issues
by seismo!sun!guy March 18, 1987

March 18, 1987

1. Should time() return an implementation defined time representation or should it return elapsed seconds since midnight January 1 1970 GMT? The current POSIX draft already states that it returns the latter; do we want to change this? If it does not return elapsed seconds, should the name "time" (or the type name "time_t") be changed (so as to noisily break existing code, rather than quietly breaking existing code?) X3J11 also has "time" and "time_t", although since they're not defining an OS standard they do not require "time_t" to be an integral type representing seconds since the epoch.

1 0

Re: northamerica timezones & Saskatchewan
by seismo!nbires!vianet!devine March 17, 1987

March 17, 1987

Darwyn Peachey peachey(a)sask.UUCP writes: > If I am reading your "northamerica" (version 3.1) timezone file correctly, > it appears to be inaccurate concerning the province of Saskatchewan in > Canada. You seem to assume that all of Canada observes the DST rules. > In fact, Saskatchewan is always on standard time and has been for several > years (up to 20, I'd guess). To be more precise, we are always on daylight > time, since we are geographically in the Mountain zone, but we use Central > Standard Time year round! The information I have found on Saskatchewan Daylight Time is this: 1962-1971 Variable (each locality may have done something different) but it seems to be last Sunday in April to last Sunday in October (September in 1960-1) 1972-present? Observed in entire province except in the far-eastern part (that part is on Central Standard time all year) The western part is on the last Sunday in April to last Sunday in October schedule I don't know where the machine 'skorpio' is but I infer that it is in the Eastern part of Saskatchewan. Does anyone have access to an official publication of Canada that describes DST? Does such a publication exist? Bob Devine

1 0

Re: northamerica timezones & Saskatchewan
by Arthur David Olson March 16, 1987

March 16, 1987

> Saskatchewan is. . .always on daylight time, since we are geographically > in the Mountain zone, but we use Central Standard Time year round! > Thus, there is always a four hour time difference between us and Hawaii. . . > Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909 With a machine name like sask, I'll willing to accept your word as authoritative! Is "CST" the right time zone abbreviation to use in your neck of the woods? Is this: Zone Canada/Saskatchewan -6:00 - CST the right line to have in the northamerica file? --ado

1 0

northamerica timezones & Saskatchewan
by seismo!ihnp4!skorpio!peachey March 16, 1987

March 16, 1987

If I am reading your "northamerica" (version 3.1) timezone file correctly, it appears to be inaccurate concerning the province of Saskatchewan in Canada. You seem to assume that all of Canada observes the DST rules. In fact, Saskatchewan is always on standard time and has been for several years (up to 20, I'd guess). To be more precise, we are always on daylight time, since we are geographically in the Mountain zone, but we use Central Standard Time year round! Thus, there is always a four hour time difference between us and Hawaii (whereas the temperature difference varies from -130F to +20F). Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909

1 0

Re: Dumb questions about GMT offset in tm structure
by Arthur David Olson March 15, 1987

March 15, 1987

> > Dumb question #2: if there's a way to turn tm structures ... > > does .. [ being able to deduce it ] ... > > obviate the need for a GMT offset element in the tm structure? > Certainly, this is possible. . .But the zone offset information is trivially > available to localtime, it seems like it can't hurt to provide this extra > information, essentially for free. The only place I can think of that it might hurt is if someone has squirreled away tm structures in a disk file. If that's happened, the committee's desire to avoid breaking existing code would argue against changing the tm structure. Now if you change the structure's name, then code will break noisily-- something the committee seems willing to accept. -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbpavo.MIS.OH.ATT.COM!mark March 15, 1987

March 15, 1987

Dumb question #1: what applications use the offset from GMT of local time? (That is, why do we want the offset in the tm structure in the first place?) I've run across it in networking applications, such as mail, netnews, and transactions. They get char string date/time info from some other place (possibly around the world) and have to understand it. Dumb question #2: if there's a way to turn tm structures into time_t values, does the ability to do something like offset = time_of_interest - convert_tm_to_gmt(localtime(time_of_interest)); (possibly followed by offset = -offset; depending on what sex you think the offset should be) obviate the need for a GMT offset element in the tm structure? Partly. At the higher levels, what I really want to do is things like this: Convert gmtime char string to localtime char string Convert localtime char string to gmtime char string Compare two times to see which is older. Compare two times to see if one is more than X older or newer than the other Add or subtract X hours (minutes, days, seconds, years) from a time. Also, a long isn't enough to handle the times of interest. Sometimes we need subsecond precision. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Part of me wonders if a floating type could be used for time_t. Nobody wants subsecond precision on a birthdate, although they might want it for times very close to "now". I guess what I really want is a floating point where zero means "now", but that doesn't exactly work out unless you throw in a fixed reference point. Mark

1 0

Re: Dumb questions about GMT offset in tm structure
by Robert Elz March 14, 1987

March 14, 1987

Date: Sat, 14 Mar 87 13:29:55 EST From: elsie!ado (Arthur David Olson) Message-ID: <8703141829.AA01740(a)elsie.UUCP> Dumb question #1: what applications use the offset from GMT of local time? Anything which wants to record time in local time (for ease of human reading) but be precise about the zone so the precise GMT time can be reconstructed. Mailers are a prime example, the Date: line should contain such an offset (only in the 5 US zones is it allowable to use an abbreviation .. except the stupid US military one letter abbreviations; and even those 5 are only allowed in rfc822 style mail, ISO stuff always requires the numeric offset) Dumb question #2: if there's a way to turn tm structures ... does .. [ being able to deduce it ] ... obviate the need for a GMT offset element in the tm structure? Certainly, this is possible. Initially I wasn't realy impressed with the need for the offset in the struct tm because of how easy it is to obtain this way (even without the inverse functions, its not hard to do a struct subtraction (ie: multiple subtractions, with additions & multiplications to combine the answers) of the results of gmtime() and localtime()). But the zone offset information is trivially available to localtime, it seems like it can't hurt to provide this extra information, essentially for free. kre

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!cbosgd.MIS.OH.ATT.COM!mark March 14, 1987

March 14, 1987

Dumb question #1: what applications use the offset from GMT of local time? (That is, why do we want the offset in the tm structure in the first place?) I've run across it in networking applications, such as mail, netnews, and transactions. They get char string date/time info from some other place (possibly around the world) and have to understand it. Dumb question #2: if there's a way to turn tm structures into time_t values, does the ability to do something like offset = time_of_interest - convert_tm_to_gmt(localtime(time_of_interest)); (possibly followed by offset = -offset; depending on what sex you think the offset should be) obviate the need for a GMT offset element in the tm structure? Partly. At the higher levels, what I really want to do is things like this: Convert gmtime char string to localtime char string Convert localtime char string to gmtime char string Compare two times to see which is older. Compare two times to see if one is more than X older or newer than the other Add or subtract X hours (minutes, days, seconds, years) from a time. Also, a long isn't enough to handle the times of interest. Sometimes we need subsecond precision. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Part of me wonders if a floating type could be used for time_t. Nobody wants subsecond precision on a birthdate, although they might want it for times very close to "now". I guess what I really want is a floating point where zero means "now", but that doesn't exactly work out unless you throw in a fixed reference point. Mark

1 0