- tz - lists.iana.org

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

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

Jan. 30, 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

Re: Parsing /etc/TIMEZONE
by seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Dec. 21, 1986

Dec. 21, 1986

One thing that bothers me about the new parsing routine for /etc/TIMEZONE (I can't say at this point whether it is different from the old one) i that fgets calls malloc(). One of the uses which I have for ctime strictly forbids the use of either malloc() or the standard I/O libraries. Ron Tolley

1 0

Re: Default timezone
by seismo!sun!guy Dec. 20, 1986

Dec. 20, 1986

I mean local wallclock time (conversion rules out of an instruction would be a little wierd... but this processor has a "load.time" instruction, or something like that, which returns local wallclock time, 64 bits, high precision, and lasts forever...) By "local wallclock time", do you mean local wallclock time (DST and all), or just the number that it was originally set to at time T plus the number of clock ticks since time T? If it's the latter, it could just as easily keep "UNIX time". The time system call (I can't remember now if its in the kernel or not or if time(2) just does this in each user's code) gets that value and then applies basically the reverse transformation of localtime() to get GMT to return to the user... My point was that the method of discovering what local wall clock time is shouldn't be constrained at all in the standard. But in most cases you get wall clock time by doing "time" or "gettimeofday" and feeding that to "localtime"; if you do that on this machine, and it's OS is really UNIX-compatible, the fact that the hardware keeps some flavor of local time is irrelevant. The application would get "UNIX time", and then call "localtime" to convert that back to local time in some time zone. The standard *already* constrains the way you discover what local wall clock time is; you get "UNIX time" from "time" and feed it to "localtime". Hardware that keeps "wall clock time" is, in a POSIX system, an obstacle to overcome (you have to convert "wall clock time" to "UNIX time") rather than something that makes certain operations easier. If you really don't want the standard to constrain how you get local wall clock time, you'd have to add a function like "localtime" that takes *no* arguments, and returns the broken-down value of the wall clock time, or add a function like "time" that returns wall clock time as a "time_t" and use "gmttime" or something if you want to break that down. The S5R3.1 scheme does handle this, by having "init" put the time zone in its environment. No, that only gets it to the children of init, and their children, until someone types "env - sh" to their shell... How is typing env - sh to your shell different from typing TZ=Europe/Albania; export TZ to your shell? In either case, the user is explicitly reaming out their environment. Are you saying that even if a user reams out their environment, programs they run should get local time by default? I neither agree nor disagree with this; I haven't seen what I consider to be a good argument either way. Actually, "settz()" could be implemented in the S5R3.1 scheme. Yes, the problem is whether AT&T will do it or not. Since some way of permitting a program to get all time conversions to be done with the "official" local rules is required, the standard must include something like that. The S5R3.1 scheme already has a way of doing it; you open "/etc/TIMEZONE", read it, and "putenv" the value in there. However, 1) you don't want to have to write the same idiom 500 times for 500 programs, and 2) you want the standard to have a way of requesting "official" local time without having to know so many details of how the rules are specified, so that the standard doesn't have to require you to use TZ and all the baggage (i.e., the ability for the user to choose which rules they want) that this drags in. So you want some way of saying "please give me local rules", rather than some way of getting the "name" of the local rules and some way of saying "please give me this set of rules". "settz((char *)NULL)" seems fine to me. (The behavior when "settz" is passed a string rather than a null pointer could be left up to the implementation, in case any implementor might object to a fully general scheme.) If the standard does include that, AT&T could implement it, and would have to if they wanted to sell to somebody who required POSIX compliance.

1 0

Re: Default timezone
by seismo!sun!guy Dec. 20, 1986

Dec. 20, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. Not really. I tested Arthur Olson's code, which doesn't read "/etc/TIMEZONE" but *does* read a file of rules, with a program that just converted the current time using "ctime". The difference in time was negligible. It probably took more time to load the test program(s) than it took to read the files - and this was a version that read files that were written with a machine-independent byte order; it wasn't just doing one big "read". Even using Sun XDR, it wasn't a major difference. (Also, remember that a program won't read "/etc/timezone", or the setup files, *every* time it calls "ctime"; once is enough. Yes, this means you have to restart long-running programs if the rules change, but that shouldn't happen too frequently.) This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Unfortunately, it's also incomplete, unless you extend "ftime" to return a table of DST on/off times. Recompiling every program that uses "ctime" because the U.S. Congress extended DST is a pain; it's worse in countries that seem to change the rules on a yearly basis....

1 0

Re: Default timezone
by seismo!cbpavo.MIS.OH.ATT.COM!mark Dec. 19, 1986

Dec. 19, 1986

While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Mark

1 0

Re: Default timezone
by seismo!sun!guy Dec. 18, 1986

Dec. 18, 1986

> From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Default timezone > Our reasoning is that in the majority of cases this is an error > by the system administrator in setting or exporting the TZ > variable and it is necessary for someone to notice the error. As > it stands most developers/porters set the TZ to their local time > zone (who is it that uses PST?!) and then never notice that their > product has problems. What "problems" does setting TZ to the local time zone (which *IS* PST here where we do *our* development) disguise, and why does defaulting to GMT if TZ is missing or empty reveal them? > Using wall clock as default merely propogates this development > problem and results in products having problems when they are > used in other environments. So does setting TZ in "/etc/init". The only way to flush these problems out before the product is released is to *deliberately* run it with timezones other than the developers' zone. > From: seismo!cuuxb!dlm (Dennis L. Mumaugh) > Subject: Re: Parsing /etc/TIMEZONE > I do like the idea of a single place for establishing the TZ for > a system. It makes it very easy for new administrators. Olson's scheme has this, as well; you just use the "-l" flag when running "tic". It causes a link name "localtime" to be made to the time zone specified as the argument to "-l". > Another problem with a routine to read and parse /etc/TIMEZONE is > what does one do for non-ATT shells (c shell and others) the > setting of TZ in the environment differs. That's why having > /etc/init set things up is good. That guarentees a "standard > environment". It is true someone could diddle with it, but I am > more concerned with naive users than others. You're going to need a routine to read and parse "/etc/TIMEZONE" anyway. "uucico" will have to use it; it does NOT want to use "TZ" to indicate what the local time zone is, precisely *because* somebody could diddle with it. > From: Robert Elz <seismo!munnari!kre> > Subject: Re: Default timezone > Date: Wed, 17 Dec 86 11:09:09 cst > From: cuuxb!dlm (Dennis L. Mumaugh) > Message-ID: <8612171709.AA08584@cuuxb> > The issue here really, is how does a programmer exercise his > "conscious choice" to get wall clock time? > If you wanted to define /etc/TIMEZONE or something as a > file containing the right TZ string, so that programs that > need wall clock time would be required to go read (and parse) > that file, then that would be a solution. But you had better > be prepared to define the format and name of that file, > and stick to it forever more. You should also be prepared > to go and find all the standard processes that need this > (like uucico, and others) and insert the relevant code. Actually, any scheme would require you to find all the processes that understand this, and insert some code to ensure that the machine's time zone is used. > Personally, I prefer a slightly simpler interface. That > doesn't preclude putting the information in a file, of > whatever format you prefer, but it should be the time > functions that read the file, not the user's code. Absolutely. This could be done in the S5R3.1 scheme, by providing a function to read "/etc/TIMEZONE". You could even call this function "settz()" (see below). > This also allows for more implementor flexibility, she > has lots of choices she can make as to how to obtain > the local wallclock time - from a simple ascii file, > from a precompiled binary file, from a network information > server, from the kernel via a system call, and I assume > lots of others. I can even imagine processors where local > time might be available as an instruction in the instruction > set (I can imagine such processors because we have one...) Do you mean "local wallclock time" or "local conversion rules"? With current UNIX interfaces, and with all the proposals that have popped up so far, all you could do is get the latter and use them to convert the result of "time()" to local wallclock time. > Certainly having local wall clock time be the default > when TZ is not set is a very sensible way to do things, > as it means that the system administrator doesn't need > to set up TZ for every process in the system, The S5R3.1 scheme does handle this, by having "init" put the time zone in its environment. > Most of the people on this list seem to feel that the > right way for a program to choose wallclock time explicitly, > is to putenv() TZ to a null value. Personally, I still think > settz() is a cleaner interface. Actually, "settz()" could be implemented in the S5R3.1 scheme. Assume that the time conversion code takes some string and uses it to set up the conversion rules (details deliberately left unspecified). "tzset" would use the value of 'getenv("TZ")' for this string. "settz" would do the following: if its argument is a null pointer, read "/etc/TIMEZONE" and use the string located therein; if its argument is a pointer to a null string, use GMT; otherwise, use its argument as the string in question. There is one issue here; should a process only be able to affect how its UNIX time <-> local time conversions are done, or should it also be able to affect any children it spawns? The former is effected by "settz"; as it stands, the later requires you to change TZ, either by eliminating it, nulling it out, or setting it from "/etc/TIMEZONE". "uucico" would probably want to affect its children; some other program might not. I do have another question; are we discussing UNIX or POSIX here? If the latter, should POSIX require that anything be supported other than local machine time? It may be convenient to permit users to specify other time zones, but user convenience is somewhat outside the scope of 1003.1, at least. POSIX should not *preclude* a user overriding the default time zone, and as such must provide a way for a process to override the user's override and get the default timezone; it probably must also provide a way to force its children to use the default time zone, as well. For this, all you need is a function that says "set time zone to the default"; the full generality of "settz" isn't necessary. You could have POSIX just define the behavior of "settz(char *)NULL)" and leave the rest up to the implementation. POSIX must also require that an application must, by default, get some "reasonable" time zone information, which would either be the system default time zone or, if supported, a user-specified time zone. It must do so in such a way that no application need explicitly set up anything (such as snarfing the right value of TZ from "/etc/TIMEZONE") in order to get this information, and in such a way that no application need be run in a special environment (i.e., saying "the way you set it is to put it in "/etc/profile" is out). Olson's scheme provides most of what is needed from the POSIX standpoint. "settz" could be added to the S5R3.1 scheme, and it would be equivalent (from the program's standpoint) to Olson's scheme. Both Olson's scheme, and the S5R3.1 scheme with "settz" added, would provide a way for a program to explicitly choose a particular time zone (and it would work in the same fashion in both schemes), and would use the value of TZ if one was provided. Both schemes make it simple for an administrator to set the default timezone; in Olson's scheme, you just run "zic" with the "-l" flag specifying the default zone, or make the link yourself, and in the S5R3.1 scheme you just set the "/etc/TIMEZONE" file. Neither scheme directly addresses the question of "how do you teach your children about the time zone you selected"? One way to do this would be to use "putenv"; however, that exposes various implementation details that really should not be exposed. Perhaps there should be a function like "settz" that propagates that change to children.

1 0

Re: Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

Yes, it is true that my parse routine does use standard IO. Also it is simple minded about "shell". It doesn't know about quoting or shell escapes: thus the new expanded TZ will break as there is a semi-colon in the TZ string. Oh well, what do you want for free? BTW, the init parser for SystemV Release 3.1 is not very smart either. I do like the idea of a single place for establishing the TZ for a system. It makes it very easy for new administrators. Another problem with a routine to read and parse /etc/TIMEZONE is what does one do for non-ATT shells (c shell and others) the setting of TZ in the environment differs. That's why having /etc/init set things up is good. That guarentees a "standard environment". It is true someone could diddle with it, but I am more concerned with naive users than others.

1 0

Default timezone
by seismo!cuuxb!dlm Dec. 18, 1986

Dec. 18, 1986

The issue of what time zone to use if the TZ variable is not set should be thought out a bit more. ATT has decided to use a "default" of GMT if no TZ is set or if it is NULL ( "TZ=" ). Our reasoning is that in the majority of cases this is an error by the system administrator in setting or exporting the TZ variable and it is necessary for someone to notice the error. As it stands most developers/porters set the TZ to their local time zone (who is it that uses PST?!) and then never notice that their product has problems. Using wall clock as default merely propogates this development problem and results in products having problems when they are used in other environments. The use of wall clock as the "default" ought to be a concious choice by a programmer and GMT ought to be the default whenever a time routine can't decide what timezone to use.

2 1

Resolved timezone issue? Other issues. New ctime manual page
by ado Dec. 16, 1986

Dec. 16, 1986

In this letter I'll try to: 1. Recap the discussion of the question "Should TZ, or something else (such as TIMEZONE), be used as the environment variable where time zone information is kept?" 2. Throw in my own two cents on the discussion of "How does the environment variable TZ get initialized in the first place?" 3. Summarize different ways programs might use to get time zones other than the one specified in the environment--I trust other folks will discuss this further. I've also attached a copy of my latest revised ctime manual page. 1. A few folks (me included) see putting time zone information in an environment variable with a new name (such as TIMEZONE) as a good thing. Doing so could avoid problems for "old" programs run with something such as TZ=US/Eastern or TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 in their environments. Most folks on this mailing list, though, think it best to stick with TZ. It's an environment variable whose purpose is already clearly understood as being a repository of time zone information, and it would be a nuisance to have both it and TIMEZONE. So: I'll stick with using TZ (and will also hope that someone can come up with an explanation for doing so that's both brief and more compelling that the one in this paragraph). 2. As to how TZ should be initialized--I'd hope that the standard(s) will end up providing a scheme that doesn't require TZ to be initialized at all, and that if TZ is absent from the environment then programs will deliver "the best available approximation to local wall clock time." In a scheme where time zone information is kept in files, this is easy: you just, for example, do a ln /etc/zoneinfo/US/Eastern /etc/zoneinfo/localtime or ln /etc/zoneinfo/Moon/Darkside /etc/zoneinfo/localtime and set up the time handling functions to load things from "/etc/zoneinfo/localtime" if TZ is absent from the environment. As others have shown, in a "non-file" scheme it's also possible to cope with the absence of TZ--although more code is needed for coping purposes (since you need to both know the name of the file to be used and need to interpret its contents). Either way, I think that the time zone functions are the right place to handle dealing with what local time is-- and that init is the wrong place. 3. Folks have now outlined three ways for programs to ask for variant time zones: a. The "ctime.least" method outlined in some of Ron Tolley's manual pages, in which "localtime" simply examines the TZ environment variable each time localtime is called. To get a variant time zone, you just set up TZ with the variant before calling localtime (either directly or indirectly via ctime). b. The System V Release 2.0 method, in which you must set up the environment variable TZ and then call the function "tzset" to get stuff read out of TZ for future use by localtime. c. The settz("whatever") approach, in which an explicit call is provided for switching to a variant time zone, with no fiddling of the environment required. These days, I favor standardizing the second approach. If the first approach is standardized, I think there'll be too much code written along these lines: putenv("TZ", "whatever"); printf("%s", ctime(&t)); that won't do what's expected when it's moved to System V Release 2.0 systems. Yes, requiring the "tzset" call after the "putenv" *is* a nuisance--but better a nuisance than worng results. And: while I'd favor having the standard(s) specify that local wall clock time should be used if TZ is absent from the environment, I think we'd best recognize that existing systems *don't* do so. For those applications that *must* have local wall clock time, I'd provide a standard function "tzsetwall" (the name is subject to change) that sets things up to use the best available approximation of local wall clock time regardless of what's in the environment (with a tip of the hat to Guy Harris for pointing out that this is the easy way to handle things). So: if you only *wanted* local wall clock time, you could use the code: { char ** savedenv; extern char ** environ; static char * fake[1]; savedenv = environ; environ = fake; tzset(); environ = savedenv; } and end up with code that would compile on any UNIX system and would deliver local wall clock time on any POSIX system. If, on the other hand, you *needed* local wall clock time, you would use the code: tzsetwall(); which would deliver local wall clock time on any POSIX system, and wouldn't compile at all on any existing UNIX system. Yes, you wouldn't get any results at all--but not gettting any results is better than getting worng results. --ado .TH CTIME 3 .SH NAME ctime, localtime, gmtime, asctime, tzset, tzsetwall \- convert date and time to ASCII .SH SYNOPSIS .nf .B extern char *tzname[2]; .PP .B void tzset() .PP .B void tzsetwall() .PP .B char *ctime(clock) .B long *clock; .PP .B #include <time.h> .PP .B char *asctime(tm) .B struct tm *tm; .PP .B struct tm *localtime(clock) .B long *clock; .PP .B struct tm *gmtime(clock) .B long *clock; .fi .SH DESCRIPTION .I Tzset uses the value of the environment variable .B TZ to set time conversion information used by .IR localtime . If .B TZ does not appear in the environment, the best available approximation to local wall clock time is used by .IR localtime . .if !\nX \{\ If .B TZ does appear in the environment, .I localtime will only work correctly if its value is one of an implementation-defined set of values.\} .el \{\ If the value of .B TZ begins with a slash, it is used as the absolute pathname of the .IR tzfile (5)-format file from which to read the time conversion information; if .I zonename begins with some other character, it is used as a pathname relative to a system time conversion information directory. \} .PP .I Tzsetwall sets things up so that .I localtime returns the best available approximation of local wall clock time. .PP .I Ctime\^ converts a long integer, pointed to by .IR clock , representing the time in seconds since 00:00:00 GMT, January 1, 1970, and returns a pointer to a 26-character string of the form .br .ce Thu Nov 24 18:22:48 1986\\n\\0 .br All the fields have constant width. .PP .IR Localtime\^ and .I gmtime\^ return pointers to ``tm'' structures, described below. .I Localtime\^ corrects for the time zone and any time zone adjustments (Daylight Savings time in the U.S.A.); before doing so, .I localtime\^ calls .I tzset\^ if .I tzset\^ has not been called in the current process. After filling in the ``tm'' structure, .I localtime sets the .BR tm_isdst 'th element of .B tzname to a pointer to an ASCII string that's the time zone abbreviation to be used with .IR localtime 's return value. .PP .I Gmtime\^ converts to Greenwich Mean Time (GMT). .PP .I Asctime\^ converts a time value contained in a ``tm'' structure to a 26-character string, as shown in the above example, and returns a pointer to the string. .PP Declarations of all the functions and externals, and the ``tm'' structure, are in the .B <time.h>\^ header file. The structure declaration is: .RS .PP .nf struct tm { int tm_sec; /\(** seconds (0 - 59) \(**/ int tm_min; /\(** minutes (0 - 59) \(**/ int tm_hour; /\(** hours (0 - 23) \(**/ int tm_mday; /\(** day of month (1 - 31) \(**/ int tm_mon; /\(** month of year (0 - 11) \(**/ int tm_year; /\(** year \- 1900 \(**/ int tm_wday; /\(** day of week (Sunday = 0) \(**/ int tm_yday; /\(** day of year (0 - 365) \(**/ int tm_isdst; /\(** is DST in effect? \(**/ }; .fi .RE .PP .I Tm_isdst\^ is non-zero if a time zone adjustment such as Daylight Savings time is in effect. .SH SEE ALSO .if \nX tzfile(5), getenv(3), time(2) .SH BUGS The return values point to static data whose content is overwritten by each call. .. @(#)newctime.3 2.9

1 0

mod.std.unix announcement?
by ado Dec. 16, 1986

Dec. 16, 1986

If there's no objection, I'd like to announce the existence of the time zone mailing list in a mod.std.unix article. Let me know if there are problems; if not, I plan to submit an article this Thursday or Friday. --ado

1 0

Parsing /etc/TIMEZONE
by seismo!cuuxb!dlm Dec. 15, 1986

Dec. 15, 1986

I wrote a simpler and better parse of /etc/TIMEZONE. Also note that since /etc/init already does so one could steal its code. He is my short parse. Note, it does parse System V Release 3.1 versions which have OTHER lines of garbage (comments and such): === #include <stdio.h> #include <string.h> char def_timezone[] = "GMT0"; char * gettz() { FILE * tzfp; register char *bp; register char *tbp; static char buf[132]; if ( (tzfp = fopen("/etc/TIMEZONE", "r") ) == NULL) { return(def_timezone); } while ( fgets(buf, sizeof buf, tzfp) != NULL ) { if ( buf[0] == '#' || buf[0] == '\n' ) continue; buf[strlen(buf)-1] = '\0'; /* strip newline */ if ( strchr(buf, '=') == NULL ) continue; for (tbp = buf; ; ) { bp = strtok(tbp, "; \t"); if ( bp == NULL ) break; /* should be xx=xxx; */ if ( strchr(bp, '=') != NULL && strncmp( bp, "TZ=",3) == 0 ) break; tbp = NULL; } fclose(tzfp); return(strchr(bp,'=')+1); } fclose(tzfp); return(def_timezone); } ===== Note that we use the stdio AND SysV string functions. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 13, 1986

Dec. 13, 1986

> 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ > variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. True, but assuming that "/etc/TIMEZONE" has the format TZ=<name> that file can easily be parsed by a program other than a shell. (Nothing more is needed in "/etc/TIMEZONE"; e.g., if you want to export "TZ" after fetching it from "/etc/TIMEZONE", you just do "export TZ" after sourcing "/etc/TIMEZONE". Given that, if the argument to "settz" were "(char *)NULL", "settz" could fetch the machine's local time zone by doing something like register int fd; static char tzbuf[SIZE + 1]; register int i; fd = open("/etc/timezone, O_RDONLY); if ((i = read(fd, tzbuf, SIZE + 1)) < 0) return (-1); /* * The "SIZE + 1" is a hack to detect overly-long files. * We advertise SIZE as the maximum size, and if there's anything * after it, we complain. */ if (i == SIZE + 1) return (-1); if (i < 4) return (-1); /* doesn't start with "TZ=" */ if (strncmp(tzbuf, "TZ=", 3) != 0) return (-1); /* doesn't start with "TZ=" */ if (tzload(tzbuf + 3, &s) == -1) return (-1);

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!nbires!vianet!devine Dec. 12, 1986

Dec. 12, 1986

My, this proposal sounds familiar :-). I've since been won over to the stick-the-stuff-in-a-file-and-use-functions party. > 2. Init (/etc/init == process 1) reads and parses this file and > sets the environment of all children processes with the TZ variable... There is no guarentee that some fiend doesn't step on the value before passing it to someone else. Even if there are no fiends, there may be remote users. One needs a mechanism to find out the correct timezone information from an unimpeachable source. "Source'ing" /etc/timezone is not slick if your process isn't the Bourne/Korn shell. > 3. The TZ variable has new syntax and fields. First as sample > TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 > Comments: > The new syntax for TZ allows for any time zone rule, but only > allows ONE change per year. The varialbe must be modified and > reset for the year being printed. Thus is TZ is set for 1987 a > full ctime for a previous year will result in odd information for > a few days each spring and fall (US). This goes to the heart of the proposal. I tried hard to convince myself that one year's definition suffices. However, it is certainly possible to do multiple years and to hide the nastiness as well by using a collection of files. When I proposed a redefinition of TZ to hold more info, it was in part because I didn't want to break UNIX conventions. I guess that is one of the underlying concern in this proposal too. Unfortunately they were always broken with respect to correctly handling the world's variety of timezones. Bob Devine

1 0

Re: ATT System V Rlease 3.1 and Timezones
by seismo!sun!guy Dec. 12, 1986

Dec. 12, 1986

1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. You'd better make that "can be source by any *Bourne shell* that wishes". There is no guarantee whatosever that a given user will ever have a Bourne shell running in their session; e.g., "uucp" usually has "uucico" as its login shell. "uucico" would have to read "/etc/TIMEZONE" itself, and pass the first line in that file to "putenv" after stripping off the trailing newline (remember, you do NOT want to permit the user to do TZ=EST5EDT uucp ... in order to force "uucico" to think it's after 11PM and thus force it to make the call to the target system immediately). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This is totally wrong. For one thing, as you point out later, it makes the incorrect assumption that only the rules for the current year are of interest. For another, it sets TZ to a complicated string which also requires work to generate; how many of you who don't happen to have calendars that give Julian dates on every day page want to go through the trouble of figuring Julian dates out? (This is also a botch in the S5 accounting routines; you have to provide the Julian date of all the days to be considered holidays. A computer can figure that out much better than a human can.) Both Arthur Olson's and HP's schemes, which put the rules into a file and which just provide the *name* of the file to fetch them from, are vastly superior. Olson's code includes a compiler that makes generating the rules quite easy. 5. A new sequences of time functions [setcftime,ascftime,cftime] Oh boy, just what we need, a *third* set of functions, different both from ANSI C and from the HP-X/Open ones! AT&T-IS should either drop these functions in favor of one of the existing ones or get one or the other or both bodies to adopt theirs. 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. HP's scheme, at least as presented in the X/Open stuff I saw, is much better. Instead of a set of files specific to time formatting, they provide a general "string catalog", so that you can fetch messages, time and date format strings, etc. for the particular language and cultural environment. Having a "/lib/cftime" directory is just a hack. (Also, what does the LANGUAGE variable contain? For the US, would it be ENGLISH or "usa_english"? The former is incorrect; I believe the date format in Britain, for example, is different from that in the US, so just stating the language is insufficient.) 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Why is this necessary, if there is a LANGUAGE variable? Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It also doesn't look like it can handle things like South Australia's switch from CST to EST. It seems like a trivial change to store a table of TZ variables for each year. I hope by "store a table" you mean "store a table *in a file*". This table could get pretty big if you really want it to specify the rules for the entire range of valid UNIX times. All in all, none of this is very good. Others have done it much better; AT&T-IS would be best advised to leave this *all* out of the SVID, and be prepared to do it differently in future releases.

1 0

ATT System V Rlease 3.1 and Timezones
by seismo!cuuxb!dlm Dec. 11, 1986

Dec. 11, 1986

The P.55 Timezone Proposal has been sent to a low level developer at ATT Summit, NJ. The current reading is that due to schedule pressures there is little likely-hood of anything being adopted by ATT unless it is part of ANSI C for the next year or so. It also appears that none of the subscribers to the mailing list are aware of changes and directions for recent releases of ATT software so here is a summary: 1. The TZ environment is set and maintained in the file /etc/TIMEZONE and is a Bourne shell file that can be sourced ( . /etc/TIMEZONE) by any one who wishes. 2. Init (/etc/init == process 1) reads and parses this file and sets the environment of all children processes with the TZ variable. It is thus propagated through cron, login and su. [And thus to csh (just for Mark :-) ]. (Feature in System V Release 3.1 and following). 3. The TZ variable has new syntax and fields. First as sample TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00 This says the offset from GMT is 3 hours 15 minutes and 23 seconds; Alternate time starts on Julian day 281 at 2am and reverts on Julian Day 315 at 1am. Alternate time is offset from GMT by 2 hours 25 minutes and 12 seconds. Note negative time offsets are East of Greenwich and thus -5:00 ougt to be somewhere in Russia. An example of a Southern Hemishpere setting for perhaps the Cook Islands (not to be considered a real thing, just a cooked example (no pun): TZ=KDT9:30KST10:00;64/5:00,303/20:00 For TZ strings with no time specified for the change (Julian date only) the change of time defaults to midnight local time. 4. If no TZ variable is set or exists default timezone rules are for GMT. 5. A new sequences of time functions [setcftime,ascftime,cftime] allow variable formats for time (similar in concept for the funny formats for date). int cftime(buf, fmt, clock) char *buf, *fmt; time_t clock; 6. A variable LANGUAGE is used to specifiy the language of the output [default is ENGLISH with /lib/cftime/usa_english ] the default file. Files in /lib/cftime specify the default names and abbreviations of the days and months, as well as default strings for date and cftime (Europeans use dd/mm/yy and USA uses mm/dd/yy) and such. 7. The environment variable CFTIME can be used to specify the default format string for cftime related functions and programs -- date now uses cftime. Comments: The new syntax for TZ allows for any time zone rule, but only allows ONE change per year. The varialbe must be modified and reset for the year being printed. Thus is TZ is set for 1987 a full ctime for a previous year will result in odd information for a few days each spring and fall (US). It seems like a trivial change to store a table of TZ variables for each year. The cftime additions are useful for international situations but still the TZ rules are a bit parochial. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm

1 0

Re: TZ, ZONE, TIMEZONE, settz(), ... ?
by Chris Torek Dec. 11, 1986

Dec. 11, 1986

I agree with kre: The original design was wonderful. The major problem was that it was not---quite---compatible with 4BSD and with SysV. Yet the incompatibilities were in areas that everyone agrees were weak, and, moreover, in areas that were mutually incompatible anyway! Any new standard *must* break some code. Let it break code that was acknowledged insufficent, and by replacing it with code that has been tested and found satisfactory. Chris

1 0

comments of proposals
by seismo!nbires!vianet!devine Dec. 10, 1986

Dec. 10, 1986

Excuse the delay in responding to some of the issues, things have been rather hectic. Some mail may have been dropped locally (sorry if I'm talking about something that is solved). 1. Ctime functions. I favor the following small collection: char* ctime(time_t) struct tm* localtime(time_t) struct tm* gmtime(time_t) char* asctime(struct tm*) time_t mktime(struct tm*) int settz(char*) /* set up a user selectable timezone */ int strftime(char*, int, char*, struct tm*) These supply the time conversion capabilities needed. This set can be extended with internationalization functions that parallel ctime() and asctime(). "Maybe" category: int strfastime(char*, int, char*, struct tm*) int systz() -- 1) set up the system default timezone -- 2) not needed if a certain string passed -- to settz() tells it to use the local -- system timezone (settz("LOCAL") ? ) -- (internationalization problems?) int yearlength(int, int) [see comment below] Not included are: long timezone; /* yuck */ int daylight; /* yuck */ int dysize(int) [see comment below] char* tzname[2] /* too limited */ timezone() zonetime() -- I haven't seen the definition of this HP's nl_*() functions I have submitted a group of functions to Rich Salz for posting to mod.sources that, while not yet complete, do deal with the many different country-dependent changes to calendars. It is a function that takes a Christian era year and a country id and returns the number of days in that year for that country. yearlength() is more thorough that dysize(). The function's current drawbacks are that some of the dates are a bit shaky (I have on order a book from the Vatican that I was told is the definitive source) and not all countries from all years are represented. 2. Modification to 'struct tm'. I agree that 'struct tm' should be modified to adequately describe a certain time. So, three fields should be added: struct tm { /* all current fields */ time_t tm_tzdiff; time_t tm_dstdiff; char* tm_tzname; }; The elements 'tm_tzdiff' and 'tm_dstdiff' are for informational and, more importantly, for the mktime() function so that it can correctly convert any 'struct tm' into a time_t. Both are set to the time_t equivalent of zero for the structure filled in by gmtime(). 'tm_tzdiff' holds the difference in seconds (or whatever time_t is defined to hold) for the timezone difference from UTC. 'tm_dstdiff' is the same but for daylight saving time (is there a better name that describes the seasonal clock changes? [see note]). The 'tm_tzname' is the name of the timezone used when filling in the structure. Its role is informational and also serves as a guide to going from 'struct tm' to a time_t. [note: the city of Denver looked at the possibility of going to a clock change for the high-pollution period of December-February where temperature inversion and reduced auto efficiency in cold weather result in very high carbon monoxide levels. Changing the clocks so that Denver would, in effect, be in Central Time instead of Mountain Time would help reduce the levels because the sunlight would alleviate some. Consider this a LST - lung saving time :-)] 3. TZ and TIMEZONE For current programs that use it, TZ must be kept as is. The new variable TIMEZONE should be defined to handle the wide range of possible and different timezones that TZ can't handle. Its format could be open or tightly defined; I haven't given this enough thought. Bob Devine [ in case you're interested in what caused the havoc around here, no, the entire place is not shutting down as happened to me at UNISYS (nee Burroughs). ViaNetix just got sold to a company whose name I can't yet give out and we changed what machine is known as 'vianet'.]

1 0

Re: timezone proposals for P1003
by seismo!zotz.cs.utexas.edu!jsq Dec. 9, 1986

Dec. 9, 1986

The current state of timezones in P1003 is that there is a proposal, P.55, which is one step past the prevrious form, RFC.001. You've seen the text for oboth on mod.std.unix. I haven't yet attempted to get P.55 adopted as part of the actual document. This is because a) I'm stilll waiting for HP to produce their long-awaited alternative proposal and b) I'm stuck in L.A. and won't be at the meeting this week. Simplicity has been stresssed in discussing timezones in P1003 meetins. Members have seen your (and others') previous omments. I expect to get the committee to consider actually adopting P.55 at the next meeting in March. There has been no noticable objection from the AT&T reps or anyone, really, thus far, except that HP want their proposal instead (though no one has seen it yet). I would strongly recommend that any needed changes to P.55 be gotten to me before March and any points I don't know about tha should be raised in discussion be relayed.

1 0

Conversation with Ron Tolley
by ado Dec. 9, 1986

Dec. 9, 1986

Ron Tolley of Hewlett-Packard called Friday. I'd like to relay a couple of points Ron made (points which may or may not reflect official corporate policy of H-P, blah blah blah), add some notes of my own (notes which may or may not reflect official policy of the National Institutes of Health, blah blah blah), and ask for comments. 1. Setting up "new" time zone handling software to deal with environment variables such as TZ=US/Eastern may make for problems when running "old" executables that expect the TZ environment variable to be of the form TZ=EST5EDT where, depending on the quality of an implementation, "problems" here can range anywhere from getting core dumps to getting incorrect results. As others have noted, staying strictly with the current System V TZ=<standard abbreviation><offset from GMT><daylight abbreviation> system can't work--for example, with TZ=EST5EDT there'd be no way to tell whether a user wanted Canadian or US Daylight Saving Time rules applied. The possibilities I see: a. Continue to demand that the TZ environment variable be of the form TZ=<standard abbreviation><offset from GMT><daylight abbreviation> (a possibility I'd dislike). b. Set things up so that, for example TZ=EST5EDT asks for US rules to be used while TZ=Est5Edt asks for Canadian rules to be used--although either of the above would "EDT" to be used in the output of date(1) and such. This will, of course, meet with the disapproval of those who think case sensitivity in UNIX is a bad thing. :-) c. Set things up so that the TZ environment variable is of the form TZ=EST5EDT and so that a new environment variable such as TZTYPE=Canada tells the type of time zone rule to be applied. d. Set things up so that instead of setting TZ=US/Eastern you instead use some new environment variable--for example ZONE=US/Eastern With this approach, old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. (Implementation point: new software would presumably first look for "ZONE" in the environment and then fall back on "TZ" if "ZONE" was absent from the environment.) e. Throw caution to the wind and set things up so that TZ=US/Eastern is used (a possibility that Ron Tolley dislikes). My current leaning would be toward possibility 'd' above--with careful documentation of tzset's habit of looking for ZONE and then TZ. 2. Ron noted that H-P's approach to getting guaranteed local wall clock time is to use the 4.?BSD "gettimeofday" call. This contrasts with approach demanding that local wall clock time be returned by "localtime" if there's no TZ environment variable. The H-P approach does have a real backward-compatability advantage. If, in trying to ensure that I'm going to get wall clock time, I write code that zaps TZ from the environment and then does tzset(); and localtime(); calls, the code will happily compile and run on existing System V systems-- and may give wrong results. If, on the other hand, I write code that calls gettimeofday(); the code won't compile at all on existing System V systems. The bad news is that I won't get any results at all; the good news is that I won't get wrong results. One possibility I'd see: drop the demand that local wall clock time be used if TZ is absent from the environment, and add a function such as walltime() that returns "the best available approximation of local wall clock time regardless of the setting of the TZ environment variable." It would be a close analog of "gmtime". --ado

2 1

Re: walltime vs localtzset
by ado Dec. 8, 1986

Dec. 8, 1986

Guy Harris's point on localtzset being much easier to implement than walltime is very well taken. Of course, the real name will need to be different to avoid conflicts between localtime and localtzset on systems with only six characters worth of external identifiers. Maybe tzsetlocal? --ado

1 0