- tz - lists.iana.org

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

mod.sources posting; mktime
by Arthur David Olson Feb. 22, 1987

Feb. 22, 1987

I've passed on new time zone stuff to some other folks on the list; after their editing, the stuff should be posted to mod.sources. It will (in all probability) include "food for thought" code for six (count 'em, six) functions for turning time_t's into struct tm's and back: struct tm * localtime(time_t t) struct tm * gmtime(time_t t) struct tm * offtime(time_t t, long offset) time_t timelocal(struct tm * tmp) time_t timegm(struct tm * tmp) time_t timeoff(struct tm * tmp, long offset) localtime and gmtime are our old friends. offtime is like gmtime except that the given offset (in seconds) is used in generating the return value. (You want to do this, rather than adding the offset to the time and calling gmtime, to avoid overflow problems at near-minimum and near-maximum time_t values.) timelocal, timegm, and timeoff "invert" their counterparts (well, actually, they just try to do an adequate job). The troff-ish assumption with localtime and timelocal is that "the same local time conversion rules must still (or again) be in effect" when timelocal is called as were in effect when localtime was called to get the "right" inversion. None of the inverting functions gives a hoot about tm_isdst. There's surely a better way to do things. --ado

1 0

Re: When to use DST rules
by seismo!nbires!vianet!devine Feb. 21, 1987

Feb. 21, 1987

dreamit!jjw suggests: 1. [more than a year or two of DST rules is overkill] 2. "Since the DST rules are subject to the whims of politicians and bureaucrats, any rules beyond the next year are as likely to be wrong as right." 3. "a file containing several years of DST Rules can be expensive to search and a program to calculate DST for multiple years is unnecessarily complex." I agree that providing all rules of all years is overkill for most users. But who can say beforehand which rules are needed by a particular site. Consider how termcap/terminfo entries are provided: All possible terminal descriptions are distributed but a user can remove any unneeded descriptions. It is not correct that DST rules are completely unfathonable. Yes, they do change and one can only guess what the DST rules will be in far distant years. This only means that changing the DST database should be quicker and easier to do than for the "politicians and bureaucrats" to pass laws. So, the rule should be to provide an implementation with sufficient flexibility so that a user can use it with all rules or just those that are wanted. Don't decide for someone. Bob Devine

1 0

minutes east or minutes west
by Chris Torek Feb. 21, 1987

Feb. 21, 1987

Just a side point... pick one or the other for `struct tm', then stay with it. We can change all the old code now and conform to ISO, or we can buck the tide as long as we want. Having one field one way and another the other, however, is a mistake: That way lies madness.

1 0

(1) minutes east/west and (2) aust time
by Snoopy Feb. 21, 1987

Feb. 21, 1987

I've been watching the discussion on minuteswest vs minuteseast, and there's a point that I haven't seen brought up yet. The math is a bit less confusing if you use minuteseast. I modified date(1) to allow setting the timezone to any number of minutes west of GMT you want. It was a bit confusing typing "date -z 2:15" and having date print out something like "Fri Feb 20 20:00:00 GMT-2:15 1987". (Notice the sign change!) Turns out that if you take the time in GMT and add minutesEAST, you get the correct time for your zone. west GMT east wall clock time 10:00 11:00 12:00 1:00 2:00 minuteswest/60 2 1 0 -1 -2 minuteseast/60 -2 -1 0 1 2 Other than the pain of converting existing software, it appears that minuteseast is a better choice. ----------------- Also, does anyone know the correct timezone names for Australia? The following is from 4.3 timezone.c: -10*60, "EST", "EST", /* Aust: Eastern */ -10*60+30, "CST", "CST", /* Aust: Central */ -8*60, "WST", 0, /* Aust: Western */ It seems a bit odd to be that there is no indication of daylight time (e.g. EDT, CDT) except for the western zone, which gives "GMT+8:00" during their summer. I find it hard to believe that the Australians refer to their timezone as "GMT+8:00". Snoopy tektronix!doghouse.gwd!snoopy snoopy(a)doghouse.gwd.tek.com

2 1