- tz - lists.iana.org

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

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

Re: List of issues
by Arthur David Olson March 14, 1987

March 14, 1987

A few more issues: 1. Should time() return an implementation defined time representation or should it return elapsed seconds since midnight January 1 1970 GMT? 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?) Should the names of other functions that deal with time_t values be changed? 2. If elements are added to the tm structure, should it be renamed? 3. Even if elements aren't added to the tm structure, should it be renamed? (As Guy Harris has pointed out, the standard does not define the order in which the structure's elements appear and does not preclude adding structure elements. So the "new" tm structure might be different on different machines, whereas "old" tm structures where the same on different machines. This represents a change in the tm structure's nature, and so may warrant a change of name to avoid quietly breaking existing code.) 4. Drop mktime from standard because of lack of existing art? -- UUCP: ..seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA Elsie and Ado are trademarks of Borden, Inc. and Ampex.

1 0

List of issues
by seismo!nbires!vianet!devine March 14, 1987

March 14, 1987

Here is a list of issues that should be settled. I used Ron Tolley's message as the source. PLEASE send me any issues that you feel should be incorporated into the list. 1. Extend tm structure to contain timezone name 2. Extend tm structure to contain local timezone offset from UT 3. Extend tm structure to contain local seasonal time offset from UT 4. Eliminate the external variables daylight, timezone, and tzname[] 5. Eliminate the tzset() function. 6. Use the user's environment variable to define the timezone for that user 7. Use the user's environment variable to define timezone rules 8. Allow user to select a non-default timezone 9. Allow user to define a new timezone and set of rules Starting next week (Mon = 3/16/87), I will send out a "ballot" on a single issue. Send me your vote (I will ACK your vote when it is received), and I will tally the results. When discussion on an issue seems to have stopped, I will send out the total. Does anyone have a suggestion for how best to communicate the results to the Posix general group? Guy (because you attend the meetings), would you like to present them? Likewise, does anyone have the ear of the X3J11 committe? Bob Devine

1 0

Re: List structure and standards making
by seismo!sun!guy March 14, 1987

March 14, 1987

People will be relieved in that, except for the casting (sic) into concrete of struct tm, Given that the draft does not say "'struct tm' looks like this", but just says that "the structure shall contain at least the following members", it is incorrect to say that that the structure has been cast into concrete. An OS that supports an X3J11-compliant C implementation is perfectly free to add new members to "struct tm". As it stands now, we plan to add Elz' new members, with his names for them, in a future release. Thus the current discussions on the whole time subject are rapidly becomming academic... People will be relieved in that, except for the casting (sic) into concrete of struct tm, much is left unsaid, especially things like timezones; Given that much is left unsaid, some discussions of timezone are most definitely *not* academic, and X3J11 will not render them so; various OSes that support X3J11-compliant C implementations can and will do different things here. POSIX systems will have to do something; the proposal already made to P1003 is a good start, at least.

1 0

Re: List structure and standards making
by seismo!munnari!basser.oz!john March 13, 1987

March 13, 1987

> Thus the current discussions on the whole time subject are > rapidly becomming academic Dennis, The discussions are certainly NOT becoming academic. There are a lot of people who just don't care what X3J11 says; who believe that X3J11 is irreparably broken, and intend to ignore it into the indefinite future. It may well be that ``the ANSI C is already spoken.'' For my money, the ANSI C is already buggered. Now this is not to say everyone feels like this. I am sure that people from various manufacturers feel the standard is important. But real (K&R) C is going to be around for a long time. Don't assume it will automagically become extinct with the release of X3J11. John ``Down With ANSI C'' Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john(a)basser.oz.AU (john%basser.oz(a)SEISMO.CSS.GOV) {seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john Thought for the century: The worst crime a standards-maker can commit is innovation.

1 0