- tz - lists.iana.org

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

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

Feb. 7, 1987

I'm not sure if this got out, so... 1. What other reasons can folks think of for adding mktime to the standard? The reason I've wished UNIX had such a function is that it can be useful to have an inverse to "localtime". I'm not sure it really needs to be in the standard, though; there are things that can be done in a C environment (one that is not necessarily a UNIX/POSIX environment) with the results of "localtime" or "ctime" (namely printing them), but I'm not sure what you can (or, at least, would want to) do with a time value converted from local time. It seems unlikely that somebody would actually wait for some moment of time by looping and repeatedly testing the current time, as given in the Rationale. In a UNIX/POSIX environment, "mktime" would be quite useful. I'm not sure whether it needs to be present in all C environments or not. Perhaps X3J11 should hand it over to 1003.1? (If they do, I can think of a few other things they should hand off as well!) 2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values? There already is one such function, namely "difftime". A function like "addtime" (although possibly with a "double" rather than an "int" argument, since "difftime" returns a "double") not only fits in well with "difftime", but provides a capability that is missing. It's like pointer subtraction and pointer/integer addition; having the former without the latter seems silly. 3. If an arithmetic-permitting function was available, would it be wise to eliminate the ability to handle tm structures containing "out of bounds" values from mktime? I'd be inclined to do so; I don't see the reason why they even put the ability to handle "out of bounds" values now. It seems to me that a program could just as well do the mixed-radix arithmetic entirely by itself, without getting a half-assed assist from "mktime", which seems to be what they intended. They should either have provided a function to add two "struct tm"s (where the second one represents an interval, and need not represent a valid time - e.g., you could represent "25 hours" either by "tm_hour" being 25 or "tm_min" being 25*60), or, at least, provided a separate function to "canonicalize" a "struct tm", instead of burying it in "mktime" (I could imagine a program wanting to do arithmetic on dates and times with both the values and the result being in mixed-radix form, so that they would never bother with any "time_t" value).

1 0

resolution of TZ variable?
by seismo!nbires!vianet!devine Feb. 6, 1987

Feb. 6, 1987

I'm not sure if a consensus was ever reached on the definition of how to store information about what timezone for a user. My suggestion is that "TZ" is acknowledged as the place where the timezone choice is placed. But no definition of what the string looks like is given for POSIX. It is an implementors decision as to what is placed there -- file name, TZ rules, or magic string. On this point a "should" should be used to guide the implementor in a reasonable direction (ie one of the 3 ways listed, don't come up a 4th version). Bob Devine

1 0

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

Feb. 6, 1987

Arthur suggests: > If the *only* reason for adding mktime was "to replace the capability to > do. . .arithmetic [on time_t type values]," I'd advocate simply throwing > mktime overboard ... > 1. What other reasons can folks think of for adding mktime to the standard? I would favor it just for conversion from a 'struct tm' to a 'time_t'. Lord knows that I looked at enough incorrect versions where someone tried to write it themselves and got lost! Don't ask about my first attempt several years ago... > 2. Would it be wise to add a function to the standard to permit arithmetic on > time_t type values? If there are no functions to modify a time_t or to compare one, people will invent several versions. However, this should be a C question. Can the existing practices of using 'long' variables be supported? Didn't the X3J11 people provide some functions? Can one cast from a arithmetic type to a time_t (and still get something reasonable)? I'm not sure this last question can be done if time_t is defined by a manufacturer. I favor providing only a mktime() call and guarentee the portability of arithmetic operations on the fields of a 'struct tm'. > 3. If an arithmetic-permitting function was available, would it be wise to > eliminate the ability to handle tm structures containing "out of bounds" > values from mktime? I don't understand what you mean by "out of bounds" -- the added structure members? bad data for a member? Bob Devine

1 0

Colorado Time ?!
by seismo!nbires!vianet!devine Feb. 6, 1987

Feb. 6, 1987

I have been in contact with the state representative here in Colorado who will soon be introducing a resolution in a committee to change the time zone for Colorado. This is of interest to all the folks in this TZ discussion group because of the ramifications that may result from this effort. You can skip the background info. Background:: 1. Denver Colorado (and increasingly other metro areas along what is called the Front Range) suffer from the growing pollution concerns caused by more and more people and their cars. The air quality grows particularly bad during "inversion layers" occurring in winter. Denver's problem come from very high levels of carbon monoxide. Pilots call Stapleton (5th largest airport in world) "hot and high" because of the thin air at the city's altitude. There is not much oxygen in a given volume as there is at sea-level. Mexico City has the same kind (though MUCH worse) problem. Automobile exhaust heavily taxes the capacity of the local atmospheric conditions. 2. Given the fixed problem of lots of people already living there, how is it possible to reduce CO levels? Voluntary no-drive days have been tried with minimal effect. No-fireplace laws are being passed that forbid burning on high-pollution days. Vechicle emission tests are required annually. 3. Automobile exhaust has been estimated to be 75% of the CO source. 4. Moving the night-time rush hour earlier in the day so that the warm air (temperatures drop rapidly at dusk) can more readily handle that CO hit would help reduce the average CO level by 10% and would really reduce the peak CO level. Time zone implications:: ------------------------ There are two ways that Colorado could move that evening rush hour: 1. Move to a different time zone. 2. Have year 'round daylight saving time. Way # 1 makes a lot more sense. BUT, to do so requires the approval of the US Dept of Transportation who will only seriously consider a TZ move if it is for "the convenience of commerce". So, any proposal that attempts to deal with TZs and DST may get hit with way # 2. Plan your design accordingly. I'll send more information when this issue is before the committee. Bob Devine

1 0

Timezone variations
by seismo!celerity!dreamit!jjw Feb. 6, 1987

Feb. 6, 1987

After a long discussion of the variation in European timezones seismo!mcvax!cwi.nl!dik (dik t. winter, cwi, amsterdam, nederland) states: > So what is my conclusion? It is nice to automatically switch to and from > DST, however it must be easily possible to override the rules. (In some > countries in Europe during the period 1977-1982 it was not known until a > few days in advance whether a switch would occur or not, and what day it > would occur!) The problem occurs when the rules are embedded in a library routine or a difficult to change file. If the DST rules for the local time zone are kept in a file which can be easily and quickly edited then this can be done very quickly when necessary by those who should know (people living in the local time zone). Rather than a file of rules I prefer a file of change dates along with information about how much time is to be added or subtracted and the appropriate time zone name. The format should allow for partial hours, negative savings ("daylight spending time"?) and double daylight time. Arthur Olsen's timezone compiler generates a file of the proper type. However, I am not sure it provides the necessary flexibility for quick local changes of all types.

1 0