- tz - lists.iana.org

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 11, 1987

March 11, 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 11, 1987

March 11, 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. 22, 1987

Feb. 22, 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. 22, 1987

Feb. 22, 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. 22, 1987

Feb. 22, 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

Re: When to use DST rules
by seismo!sun!guy Feb. 21, 1987

Feb. 21, 1987

This seems like overkill. Sigh. We've been through this before. Existing UNIX systems do this, and as such people may expect it. Unless I see good *hard* evidence that nobody has done this and that nobody will do it, I see no reason to go through the effort of removing this capability from the code. 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. No, they're probably more likely to be right than wrong, in most cases; it *does* take a fair amount of effort, in many countries, to change those rules. I ask this because it seems to me that a file containing several years of Daylight Savings Rules can be expensive to search You don't search the file; you load the whole thing and search a table. Several techniques can be done (e.g., binary search), to make that search faster. and a program to calculate Daylight Savings time for multiple years is unnecessarily complex. No, it is *not*! The code merely searches a table; the complexity of the code is independent of the size of the table.

1 0