- tz - lists.iana.org

Ballot # 1
by seismo!nbires!vianet!devine March 18, 1987

March 18, 1987

Since this is the first ballot, here are the balloting rules: 1. Send votes by mail to me (uucp address below) 2. If you feel that the offered choices for an issue are not sufficient, send me mail with suggested addition. If enough suggestions (or one whose argument is compelling) a new round of voting on that issue will be done. 3. Vote EARLY and only once (even if you are from Chicago). 4. If a message never got to your mailbox (you can tell by the reception of the next higher ballot) I will send another to you if it might make a difference in the total vote. 5. Results are piggybacked on ballots to reduce the number of messages. 6. Because there are X issues and not X weeks to discuss them, there will be several ballots per week. 7. I will not decide "winning" choices. I will only keep a count. 8. Discussion of each ballot in the mailing list is encouraged. 9. NOTE: Your votes are not the final say on how the Posix document is structured but are intended to provide valuable input. >> How best to forward the results is still unknown -- comments please.<< If you have any issues you want to see included, please send them to me. I am starting out with, what I hope, will be an issue that will not cause too much argument and gnashing of teeth. Bob Devine {nbires, hao, ihnp4!stcvax} !vianet!devine ----------------- This is Ballot # 1 on Posix time-related issues. 1. Fate of external variables "daylight", "timezone", and "tzname[]" a. Don't put in standard and discourage use. b. Don't put in standard and allow implementation-optional use. c. Place in standard as currently defined in SVID. d. Place in standard but with different or expanded definitions. ----------------- CURRENT LIST OF ISSUES 1. Fate of the external variables daylight, timezone, and tzname[] [ undecided ] 2. Use the user's environment variable to define the timezone for that user [ undecided ] 3. Use the user's environment variable to define timezone rules [ undecided ] 4. How user selects a non-default timezone [ undecided ] 5. Allow user to define a new timezone and set of rules [ undecided ] 6. Definition of what struct tm (or struct new_tm) contains. [ undecided ] 7. List of what time functions are needed. [ undecided ] 8. Definition of what time_t holds.-- implementation defined or seconds since some epoch (eg, 1/1/1970). [ undecided ] 9. Drop mktime from standard because of lack of existing art? [ undecided ]

1 0

Re: Dumb questions about GMT offset in tm structure
by seismo!sun!guy March 18, 1987

March 18, 1987

Sometimes we need subsecond precision. Yes, but "time_t"s need not provide subsecond precision; 4.[23]BSD-style "struct timeval" may not be ideal, but they do the job. Sometimes we care about things that happened in the 19th century (birthdates, for example.) Yes, but nothing in a UNIX system happened in the 19th century. Non-UNIX systems lacking "time_t" have done quite well dealing with times; I don't see any need to use "time_t" for every kind of timestamp any application could possibly want. It might be aesthetically "nice" to have the time representation used by the OS be the same that would be used by every conceivable application, but I don't see that it's worth the effort of changing what a "time_t" is. (There are plenty of OSes out there with the same problem; the VMS epoch starts 00:00 - local time, I believe - November 17, 1858.)

1 0

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

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

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

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

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