March 1987 - tz - lists.iana.org

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

Re: TZ list structure
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt March 10, 1987

March 10, 1987

Bob, Please go ahead. I agree that we have bantered around long enough. The summary which I mailed our recently could serve as a preliminary list of issues. I am sure that others should be added. Ron Tolley

1 0

List structure and standards making
by seismo!cuuxb!dlm March 10, 1987

March 10, 1987

While the list has been discussing time and timezones in context of the IEEE P1003 standards committee, people have lost sight of X3J11 which is much more important and further along towards casting into concrete. (Dramatic effect) As we now talk, the concrete has been laid and is hardening. (End drama). People should get out their X3J11 Draft Proposed American Standard for Information Systems -- Programming Language C (Dated October 1, 1986). This standard is ALREADY entering the balloting process. Please turn to page 151 and following: Section 4.12 -- Date and Time. The standard ALREADY covers clock_t, time_t, struct tm (without new strings or fields!!), clock(), time(), difftime(), mktime(), asctime(), ctime(), gmtime(), localtime(), strftime(). Thus the current discussions on the whole time subject are rapidly becomming academic as the ANSI C is already spoken and the C standard is currently in the comment phase -- send a comment and proposed change of ruling. The next phase is balloting and trial use. People will be relieved in that, except for the casting (sic) into concrete of struct tm, much is left unsaid, especially things like timezones; except to say if timezone is unknown or unsupported return (int)-1 in the approporiate place, and for gmtime return NULL if the offset is unknown. Also checkout the semantics of mktime!! -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

TZ list structure
by seismo!nbires!vianet!devine March 10, 1987

March 10, 1987

This missive argues for a different purpose of this mailing list. Currently it is used for presenting different proposals for how to deal with timezones, and seasonal time changes for Posix. Many times what happens is that arguments are sent out into the list on a certain point of view but no lasting effect is seen. I urge that this list be used to form a consensus on the issues and solutions. The mailing list members would then speak with one voice to the 1003 committee instead of several voices that only give disharmony. All issues seem to have been raised (one or twice or...). What would remain for us to do is to agree on how to do things. Too often messages have been sent but permanent resolve was obtained. I am willing to be the sender of the ballots and counter of votes. Note that the Posix group would have another shot at changing things and that the 1003 balloters would have final say. Each ballot would be organized in a "single issue; multiple choice for resolution" format. Example: Proposition H. The structure tm should be changed so that the current timezone is added by: 1. should add a 'char *' entry for the name 2. should add a constant sized arrary for name 3. should have an index into a standard file 4. should have an interactive prompt for the TZ name (only kidding...) 5. should not add the name Bob Devine

1 0

DST in Saskatchewan, Canada
by Justin Bur March 6, 1987

March 6, 1987

The province of Saskatchewan, normally in the Central time zone, has not used daylight savings time for the past several years. I think there was some talk of using it for the first time this year, but I don't remember. I also don't know if DST has never been used in Sask. or if it used to be used some time ago: my source is the national radio schedules of the Canadian Broadcasting Corporation, and my subscription started in 198?. I will send more precise information if I can find it, but it would probably be best to find a local source of information. I *think* sask.uucp is the University of Saskatchewan; I don't have a uucp map handy. Justin Bur -- Universite de Montreal <burj(a)iros1.uucp> seismo!think!mosart!mcgill-vision!iros1!burj

1 0