- tz - lists.iana.org

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

European time zones [forwarded message from cgcha!wtho]
by Arthur David Olson Feb. 4, 1987

Feb. 4, 1987

I've attached a note I received from Tom Hofmann, slightly edited at Tom's request. --ado ... Date: Wed, 28 Jan 87 16:56:27 -0100 From: seismo!mcvax!cgcha!wtho (Tom Hofmann) Message-Id: <8701281556.AA22174(a)cgcha.uucp> ... Subject: Time zone handling ... ... Let me say something about European time rules. First of all, I'm surprised to find the zone MET for Central Europe in file 'europe'. The correct expression is CET (Central European Time), although it's not the first time I found the expression MET. Maybe the best is a link between MET and CET. Secondly, the European time rules are much more complex than described in 'europe'. It is standardized since 1981, when most European countries started DST. Before that year, only a few countries (UK, France, Italy) had DST, each according to national rules. In 1981, however, DST started on 'Apr firstSun', and not on 'Mar lastSun' as in the following years. So we should set 1981 for FROM, and ignore the past. But also since 1981 there are some more national exceptions than listed in 'europe': Switzerland, for example, joined DST one year later, Denmark ended DST on 'Oct 1' instead of 'Sep lastSun' in 1981---I don't know how they handle things now. Finally, DST is always from 'Apr 1' to 'Oct 1' in the Soviet Union (as far as I know). 'europe' should be corrected in that sense, but perhaps you better make a query to Usenet first---maybe you'll find somone who knows more about national exceptions to European time rules. Tom Hofmann, Scientific Computer Center, CIBA-GEIGY AG, 4002 Basle, Switzerland UUCP: ...!mcvax!cernvax!cgcha!wtho

1 0

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

Feb. 1, 1987

I was VERY VERY happy to see mktime, as it turned out to be just what I needed for an application I'm supporting. (Actually, I had to alter it somewhat - the major change was that mktime speaks local time, and I needed a function that spoke UTC. Easy when I had the source, but it's worth mentioning that the UTC flavor is also useful.) What did I need it for? Well, I'm supporting a set of routines that provide X.410 style transactions over a network. These transactions have time stamps in them, and the time stamps are in ASCII, in a format that conforms (almost) to the appropriate ISO standards. These routines are mostly a cut up ctime.c, but I also had to supply functions to take strings received over the network (which are always in UTC) and do things like convert them to local time (for logs and for machines that keep time in local time), add N hours, etc. I'm enclosing the manual pages for my routines (the code itself is, I'm sorry to say, considered proprietary to AT&T, but the interface is open.) I consider this just an expedient solution, and not necessarily the end-all wonderful solution. Note that it does not provide a routine like mktime to the users, since I want to hide the time_t time from the users. (We have to worry about birth dates of parents of people alive today, so the 32 bit time_t isn't adequate. I don't really support that yet, but I don't provide user access to time_t so they won't write code now they'll be sorry for later.) Mark .TH ISODATE 3I .SH NAME isonow \- create ISO format string describing current date/time isodcmp \- compare two ISO format dates iso2local \- convert ISO date to local time iso2gmt \- convert ISO date to UTC time isoadd \- add a fixed offset to an ISO date .SH SYNOPSIS .nf .B "char *" .B "isonow();" .sp .B "int" .B "isodcmp(d1, d2);" .B "char *d1, *d2;" .sp .B "char *" .B "iso2local(date)" .B "char *date;" .sp .B "char *" .B "iso2gmt(date)" .B "char *date;" .sp .B "char *" .B "isoadd(date, days, hours, minutes, seconds)" .B "char *date;" .B "int days, hours, minutes, seconds" .fi .SH DESCRIPTION .P These routines manipulate ISO format date/time strings, as defined in the MDTP specification. Other routines may be added, as needed, later. .P .I isonow returns a character string, in ISO format, describing the current date and time. Only one of the ISO choices is used, namely: .nf yyyymmddhhmmsszzzzzE for example 19850410142954-0500E or 19850410142954+0930E or 19850410192954ZE .fi The first date is in the USA Eastern time zone, the second in the Australian Central time zone, and since isonow always returns GMT, the third sample is more typical. The trailing E means .I exact , as opposed to B for .I before or P for .I post (after.) .P .I isodcmp compares two ISO format times, telling which is earlier. It returns \-1 if the first is earlier, 0 if they are the same, and +1 if the second is earlier. .P .I iso2local takes an ISO format date (in either Z time zone, local time, or any other time zone) and converts it to the local time zone. It returns a string in ISO format indicating the local time zone. .P .I iso2gmt takes an ISO format date (in any time zone) and converts it to the Z (GMT) time zone. It returns a string in ISO format indicating the Z time zone. .P .I isoadd takes an ISO format date (in any time zone) and adds the given number of days, hours, minutes, and seconds to it. The numbers may be positive or negative. It returns a string in ISO format indicating the Z time zone. .SH BUGS In the interests of speed, .I isodcmp does not work correctly if any other variant of ISO format is used (e.g. seconds are missing, or a Z time zone is used, or a precision is included), or if the two time zones are not the same.

1 0

a timezone list addition
by seismo!ut-sally!zotz.cs.utexas.edu!jsq Jan. 31, 1987

Jan. 31, 1987

>From: ames!scubed!ncr-sd!greg(a)sally.utexas.edu To: milano!im4u!ut-sally!std-unix(a)sally.utexas.edu Date: Thu, 15 Jan 87 16:16:56 pst Message-Id: <8701160016.AA04029@scubed> Subject: Re: time zone mailing list Newsgroups: mod.std.unix In-Reply-To: <6835(a)ut-sally.UUCP> Organization: NCR Corporation, Rancho Bernardo In article <6835(a)ut-sally.UUCP> you write: >Any interested mod.std.unix readers can mail me a request to be added. Sigh. I'm not sure I should do this after my last attempt at commentary met with such disaster, but could you put me on the list? Tks. Oh, I'm Greg.Noel(a)SanDiego.NCR.COM or greg@ncr-sd, whichever your software will accept. -- -- Greg Noel, NCR Rancho Bernardo Greg(a)ncr-sd.UUCP or Greg(a)nosc.ARPA

1 0

mktime
by Arthur David Olson Jan. 30, 1987

Jan. 30, 1987

Now that new requests for addition to the tz mailing list have tapered off (and now that the snows have stopped here in the Washington, D.C. area) I'd like to note a problem in the October, 1986 version of the Rationale document that accompanies the draft proposed C standard, and then ask some questions. The part of the Rationale document that I'm troubled by is section 4.12.2.3 on the mktime function: > mktime is an invention of the Committee to complete the set of time > functions. With this function it becomes possible to perform portable > calculations involving clock times and broken-down times. > > The rules on the ranges of the fields within the *timeptr > record are crafted to permit useful arithmetic to be done. For > instance, here is a paradigm for continuing some loop for an hour: > > #include <time.h> > struct tm when; > time_t now; > time_t deadline; > > /* ... */ > time(now); > when = *localtime(now); > when.tm.hour += 1; /* result is in the range [1,24] */ > deadline = mktime(when); > > printf("Loop will finish: %s\n", asctime(when)); > while (difftime(time(0), deadline)>0) whatever(); > > The semantics of mktime guarantees that the addition to the tm_hour > field produces the correct result even when the new value of tm_hour > is 24, i.e., a value outside the range ever returned by a library > funciton in a struct tm object. > > One of the reasons for adding this function is to replace the > capability to do such arithmetic which is lost when a programmer > cannot depend on time_t being an integral multiple of some known time > unit. Ignore the grammar and coding errors for the moment. The big problem (to me) is that code like the above is not a "paradigm for continuing some loop for an hour"--you may end up continuing the loop for two hours (or for no time at all) if the loop is executed just before a daylight saving time transition. 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 and specifying a function such as time_t addsec(time_t base, long seconds) to allow the arithmetic to be done. But the Rationale says that allowing such arithmetic is just "[o]ne of the reasons." And now, the promised questions: 1. What other reasons can folks think of for adding mktime to the standard? 2. Would it be wise to add a function to the standard to permit arithmetic on time_t type values? 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? -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

1 0

New time zone bundles available
by Arthur David Olson Jan. 3, 1987

Jan. 3, 1987

New shell archives of time zone programs and data are available; folks who are interested in getting copies should send me a note. In the new bundles I've switched from having a int settz(char * zonename) function to set the time zone to having two functions: void tzset() which sets the time zone according to the environment variable TZ, and void tzsetwall() which sets the time zone to the best available approximation to local wall clock time, regardless of what's in TZ. While several folks on the mailing list have expressed a preference for settz over tzset/tzsetwall, I can't help but believe that system vendors (who'll eventually have to bless any new standard) would favor using tzset to increase forward portability. (I'd appreciate comments on this point--unofficial and of the record, if need be--from those of you who work for system vendors.) The new bundles also include source (though, as yet, no documentation) for the POSIX mktime function; this source is a merger of work done by Guy Harris and work done by Robert Elz. I hope to submit a new time zone package to mod.sources fairly shortly. Two upcoming dates motivate this: the date on which DST rule changes take effect in the US (April 5), and an upcoming P1003 meeting in March. The more you good folks can work things over before they go off to mod.sources, the happier I'll be. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado(a)seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

1 0