Resolved timezone issue? Other issues. New ctime manual page
Arthur David Olson
ado
Tue Dec 16 21:25:23 UTC 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
More information about the tz
mailing list