- tz - lists.iana.org

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

When to use DST rules
by seismo!celerity!dreamit!jjw Feb. 20, 1987

Feb. 20, 1987

All the versions of ctime that I am familiar with apply the daylight savings time rules into the "distant" past and into the future. This seems like overkill. Certainly, people want to see the time with DST applied for the current year and it probably makes sense to apply the DST correction for the previous year. But is it really necessary to apply the DST rules when listing times for data which is 2, 3, 5 or 10 years old? 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. I ask this because it seems to me that a file containing several years of Daylight Savings Rules can be expensive to search and a program to calculate Daylight Savings time for multiple years is unnecessarily complex. If we only need to determine the rules for the last couple of years, and for the next year, then time conversions will be faster and simpler.

1 0

code for mktime()?
by seismo!nbires!vianet!devine Feb. 19, 1987

Feb. 19, 1987

Has anybody tried to write the mktime() function? If so, please send it to me. If not, I'll write it. Bob Devine

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 14, 1987

Feb. 14, 1987

However, I can certainly see uses where converting from some other timezone would be a nice ability to have - especially parsing rfc822 style Date: lines. But I think this is a pretty specialized usage, there aren't that many other applications where the necessary zone information is going to be available in just the right form. It's not specialized at all. UNIX already provides two different timezones: localtime and gmtime. If we're going to provide an inverse to localtime, where does that leave the inverse to gmtime? Most places where times are used with the zone included, the zone is converted to its zone name form, and that is not an invertible operation - there is no definable mapping from zone names to numeric offsets, so the ability to make this transformation correctly isn't going to happen all that often. I gather you don't read ISO standards or RFC's 822 or 850. The ISO standards have you say "+hhmm", e.g. +1030 or -0500. 822 and 850 let you say EST or PDT or whatever for the USA timezones, but recognizing that this convention doesn't extend outside the USA, require that the explicit zone offset be used for other zones. What's more, in cases where I simply want to convert a local time in struct tm format to a time_t, I am not necessarily going to know what the zone is. Consider the use of mktime() inside date(1). Some user types a date/time which is easy to parse into a struct tm, from there it should be possible to use mktime() to get the time_t. But if you have to know the zone first things aren't nearly that easy. It certainly isn't a constant - it depends on the particular time that the user typed. Some applications will have a default time zone (the local one), others will default to UT. But with a struct tm that was generated by gmtime or localtime; we should expect that these routines filled in the appropriate value. If we got a date string from another machine (mail, news, network transaction) the time zone should be extracted from it. I have a couple of misgivings about your implementation though. I'm not sure exactly what the point of having 2 fields for hours and minutes is - that assumes that the offset is an even number of minutes (no odd seconds) which while likely, isn't something I would want to bet my life upon (I would assume that the USG people assumed it likely that there would be no minute offsets, only even hours when doing the standard Sys III/Sys V implementation...) So, I would suggest a single field that contains the offset in seconds from GMT. In principle I agree that seconds is a better way to do it. I note, however, that minutes was good enough for ISO, and I have been unable to get any evidence that there are places that have their timezone an offset from UT that isn't an even minute. Secondly, I'm not sure why you chose to have West of Greenwich being negative. All previous uses of timezone offsets in Unix have been the other way - West of Greenwich positive. I know that the ISO standard defines it as West == negative, but its surely an arbitrary choice, its trivial to negate the value anywhere an ISO form of offset is needed, and keeping this compatability with current (old) usages (from v6 through 4.3bsd, and pwb to Sys V) certainly seems to be a worthwhile objective. I'm sorry, but given a choice between a well defined ISO standard and a egocentric UNIX implementation, I don't see any excuse for violating the ISO standard. Upward compatibility may require that external variables like timezone, TZ, or the ftime system call remain backwards for upward compatibility, but we're defining a new function here. Hell, TZ and ftime aren't even to seconds resolution, anyway. Mark

2 1

Re: mktime
by seismo!sun!guy Feb. 11, 1987

Feb. 11, 1987

> unlikely that somebody would actually wait for some moment of time by > looping and repeatedly testing the current time, as given in the > Rationale. I believe that this is exactly what "cron" does. At least, some forms of cron. The example given in the rationale, although admittedly skeletal, didn't seem to do anything to block execution, which seems odd, although on a system that doesn't support multitasking I suppose it's not too unreasonable. "cron" does a "sleep" or "alarm"/"pause" here. It can do that because it's running under UNIX, which means it also knows that "time_t" is a straightforward arithmetic type, and thus doesn't need the "mktime" jiggery-pokery that's in the ANSI C standard. If you're writing C programs that purport to be able to run on several different OSes, you probably don't want them to spin waiting for some time to arrive; you are better off throwing in #ifdefs or an OS-interface module and using the native OS facilities for blocking until some particular time or for some particular length of time. (If the ANSI C committee is trying to to make it possible to write programs like this to run in a "pure C" environment, without requiring any OS services, they're making a mistake.) Once you get to that point, you can use "time_t" as an integral type if you're writing for a UNIX/POSIX environment, or use whatever other native timing facilities other OSes provide.

1 0

Re: mktime
by seismo!hadron!jsdy Feb. 11, 1987

Feb. 11, 1987

----- Transcript of session follows ----- bad system name: elsie uux failed. code 101 554 elsie!tz... unknown mailer error 101 ----- Unsent message follows ----- Date: Wed, 11 Feb 87 10:31:58 est From: jsdy (Joseph S. D. Yao) To: seismo!sun!guy Subject: Re: mktime Cc: elsie!tz (Guy:) > unlikely that somebody would actually wait for some moment of time by > looping and repeatedly testing the current time, as given in the > Rationale. I believe that this is exactly what "cron" does. At least, some forms of cron. I do want to support Guy's suggestion of a canontime() and full arithmetic support. Joe Yao hadron!jsdy(a)seismo.{CSS.GOV,ARPA,UUCP} jsdy(a)hadron.COM (not yet domainised)

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 11, 1987

Feb. 11, 1987

The new, improved 'tm' has two offset fields: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; One would add in the tm_dstdiff if tm_isdst is true, otherwise only the tm_tzdiff is added. The mktime() call need not be concerned with translating time zones to hour:minute offests from UT, it only needs to churn through the calculations for the structure members. Ron Tolley suggested that the tm_tzdiff and tm_dstdiff values can be rolled into a tm_tzadj. I prefer the flexibility offered with the two separate values. Calculations on the 'struct tz' can more easily deal with the DST boundary conditions if both values are distinct. I would prefer to see them rolled into one offset, representing the offset that applies to whatever time is actually in the rest of the fields. My reasoning is that most programs don't care whether DST is in effect or not, they just want to know what's there. Such programs will have to always write code like this: tmp->tm_isdst ? (tmp->tm_tzdiff+tmp->tzdstdiff) tmp->tm_tzdiff instead of the far simpler tmp->tm_tzdiff Also, any program that CREATES a struct tm is going to have to figure out whether to apply dst or not, a task I don't envy. If you want to record what the dst offset was, fine, but it should be an optional component the way isdst is, that is, the tzdiff field can stand alone without it, and if dstdiff isn't filled in, it doesn't matter. What I'm suggesting here is that if the time is T+Z+D, then tzdiff would contain Z+D and dstdiff D (or -D, if you prefer); you were proposing that they contain Z and D, respectively. Mark

1 0

Re: mktime
by seismo!nbires!vianet!devine Feb. 10, 1987

Feb. 10, 1987

This message is on the mktime() function and a new struct tm. Mark Horton says: > If we're to view mktime as a general-purpose converter from struct tm > to time_t, there's a gotcha waiting: struct tm doesn't contain any > time zone information (the isdst flag doesn't help) and hence this > conversion is ambiguous, unless you assume the local time zone or gmtime > or some such thing. That's not a good assumption to make. > > In my implementation, I added two fields to struct tm, for the hours and > minutes in the time zone which resolved the ambiguity. kre says: > So, I would suggest a new function to handle mktime() with a supplied > zone, which would look at extra info in the struct tm. > So, I would suggest a single field that contains the offset in seconds > from GMT. To repeat a suggestion I made a couple of months ago, let's extend 'struct tm' with fields to reduce the ambiguity. Consider that if someone hands you a 'struct tm' without providing usage information, it is worthless because you don't know its base. The same argument applies to many other date/time representation. The new, improved 'tm' has two offset fields: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; One would add in the tm_dstdiff if tm_isdst is true, otherwise only the tm_tzdiff is added. The mktime() call need not be concerned with translating time zones to hour:minute offests from UT, it only needs to churn through the calculations for the structure members. Ron Tolley suggested that the tm_tzdiff and tm_dstdiff values can be rolled into a tm_tzadj. I prefer the flexibility offered with the two separate values. Calculations on the 'struct tz' can more easily deal with the DST boundary conditions if both values are distinct. Bob Devine

1 0

West of Long 0 : Pos or Neg?
by seismo!nbires!vianet!devine Feb. 10, 1987

Feb. 10, 1987

Mark Horton says: > In my implementation, I added two fields to struct tm, for the hours and > minutes in the time zone which resolved the ambiguity. > (both are negative for us in the USA) kre says: > Secondly, I'm not sure why you chose to have West of Greenwich being > negative. All previous uses of timezone offsets in Unix have been > the other way - West of Greenwich positive. I favor the ISO rule. Every international organization (but, I'm sure there are exceptions) has adopted the East of Longitude 0 is positive; west is negative. If we are proposing POSIX as an international standard, we should accept the international rules. The UNIX convention is unfortunately wrong. It was one of those 50/50 chances (like determining whether the flow of electicity is positive or negative) that was incorrectly chosen. Dems da breaks. Bob Devine

1 0

Re: mktime
by seismo!cbpavo.MIS.OH.ATT.COM!mark Feb. 8, 1987

Feb. 8, 1987

If we're to view mktime as a general-purpose converter from struct tm to time_t, there's a gotcha waiting: struct tm doesn't contain any time zone information (the isdst flag doesn't help) and hence this conversion is ambiguous, unless you assume the local time zone or gmtime or some such thing. That's not a good assumption to make. In my implementation, I added two fields to struct tm, for the hours and minutes in the time zone (both are negative for us in the USA; well, I guess -0 is still 0 for the minutes) which resolved the ambiguity. I'm not sure if this change can be made in general without breaking things, and it could have been done with one field. The offset defines the tme zone the actual value in the struct tm is in; the isdst flag doesn't really have anything to do with it. Mark

2 1