Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-ID: <4077@ut-sally.UUCP>
Date: Thu, 30-Jan-86 10:38:10 EST
Article-I.D.: ut-sally.4077
Posted: Thu Jan 30 10:38:10 1986
Date-Received: Fri, 31-Jan-86 02:37:37 EST
References: <3961@ut-sally.UUCP> <3976@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 80
Approved: jsq@sally.UUCP

>From: floyd!opus!ka@SEISMO.CSS.GOV (Kenneth Almquist)
Date: Tue, 28 Jan 86 21:46:36 EST
Organization: Bell Labs, Holmdel, NJ

This article proposes a method of handling time zones which I think
meets all the requirements that have been mentioned.

The offset from GMT of some timezones is not an integral number of
hours, so I specify this offset in seconds.  The idea of compiling a
complete list of time zone names into ctime is utopian, so I have
included the time zone name.  Finally, the only way to deal with
daylight savings time appears to be to specify a list of time inter-
vals during which it applies.  Putting this all together, we get the
following, which should be placed in /usr/include/tz.h:

#define TZNAMLEN 6
#define NTZLIM 30

struct tzlimits {
	time_t tzl_start;		/* when daylight savings time starts */
	time_t tzl_end;			/* when it ends */
};

struct tz {
	time_t tz_offset;		/* offset in seconds from GMT */
	char tz_name[TZNAMLEN];		/* regular name of this time zone */
	char tz_dstname[TZNAMLEN];	/* name during daylight savings time */
	struct tzlimits tz_dst[NTZLIM];	/* intervals when DST applies */]
};

extern struct tz tz;

/* end of tz.h */


It should be possible for a user to use a time zone other than the
system time zone, but on the other hand it should be possible for
programs like uucico to be able to use the system time zone regardless
of what the user does.  Ctime should not break just because the
environment has been zapped.  To meet these requirements I propose the
routine "gettz".

Gettz is invoked as "Gettz(flag)".  The first call to gettz fills in
the global variable tz.  Subsequent calls to gettz have no effect.

Normally gettz gets the local time for the machine, but if flag is
nonzero and the environment variable TZFILE is set, gettz reads the
contents of that file specifed by TZFILE into the variable tz instead.

The routines ctime and localtime call gettz with an argument of 1, so
that programs normally do not need to invoke gettz directly.
Programs like uucico which want to force the system time zone to be
used should call gettz with an argument of zero prior to the first
call of localtime or ctime.

Gettz returns a negative value when an error occurs and zero
otherwize.  When an error occurs, gettz will attempt to set tz to the
local time zone; if that fails it will set it to GMT.

For the benefit of users, the directory /usr/lib/tz contains files
specifying all the common timezones.  The user can also create his own
private timezone files using the utility maketz.  (These files cannot
be created with text editors because they are binary files.)  The
local time zone is linked to /usr/lib/tz/local.  Most versions of the
operating system will copy this file into the kernel at system boot
time and provide a system call to fetch the local time zone which will
be used by gettz, but this is not required.  (The last sentence is for
the benefit of very small machines that might find storing the time
zone in the kernel to be too costly; I may be worrying too much here.)

Any problems with this?  The main one is that distant times will not
be represented in daylight savings time; I don't think that this is a
problem because times before Jan 1, 1970 cannot be represented anyway,
and it is a matter for speculation what the daylight savings time rule
will be in the year 2000.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)

Volume-Number: Volume 5, Number 24