- tz - lists.iana.org

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

March 17, 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 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

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

Are these limitations in the mod.sources time zone stuff worth worry?
by Arthur David Olson March 14, 1987

March 14, 1987

Completely off the standardization track for a moment. . . There are some limitations in the time zone stuff that was recently posted to mod.sources; I'm wondering if other folks have opinions on whether the limitations are worth worrying about, or if folks have inspired changes to the code that will get around the limitations. If you're not the nit-picking type, please feel free to ignore this letter. A preamble: the format of the files stored in the /etc/zoneinfo directory was designed to keep the files small and thus to keep down the overhead involved in reading the time zone information from disk. For example, here on Elsie, the "/etc/zoneinfo/US/Eastern" file weighs in at 814 bytes, which means that the time zone information fits in one logical disk block. And now. . . 1. While the file format allows big-endian and little-endian machines to use the same (file-server-provided) file to get time zone information from, it can't be used both by (traditional) machines that want to have signed time_t's and by (kre-controlled Australian) machines that want to have unsigned time_t's. Is this worth worrying about? Should the transition times be stored as "long long"s, doubles, or text? Does the added utility warrant the extra storage? 2. There are all those nasty "MAX"es built in to tzfile.h (and, by reference, into localtime et al.): #define TZ_MAX_TIMES 370 /* Maximum number of transition times */ #define TZ_MAX_TYPES 10 /* Maximum number of local time types */ #define TZ_MAX_CHARS 50 /* Maximum number of abbreviation characters */ Are the limits worth worrying about? Should localtime et al. do memory allocation to overcome the limits? Should the functions buffer some of the time zone informtion and go to disk if information that's needed isn't in the buffer? 3. And then there's Saudi Arabia. (I trust folks saw the recent Scientific American article on newly available digital watches that, when fed longitude and latitude, will provide local solar time-- this allows Moslems to observe daily prayers.) To do Saudi Arabia right--or at any rate, to do it right to the second--you need about 2000 local time types. Since, these days, local time types are stored on disk as unsigned chars, you can only get 256. The easy way out would be to encode time types the same way that transition times are encoded; this would about double the size of time zone information files. Is the added functionality worth the size doubling? Is the problem even worth worrying about? Is there a better way to deal with it? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

Dumb questions about GMT offset in tm structure
by Arthur David Olson 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?) 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? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0