RRelay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Subject: v08i085: Public Domain (Table Driven) ``localtime'', Part01/03
Date: Sat, 28-Feb-87 06:49:08 EST
Posted: Sat Feb 28 06:49:08 1987
Date-Received: Sun, 1-Mar-87 13:52:19 EST
Submitted by: Arthur David Olson <a...@elsie.UUCP>
Mod.sources: Volume 8, Issue 85
[ This is the latest release of the table (file) driven
ctime(3), originally released as "settz" in Vol 4 issue 14.
Normally, I don't post mod.sources articles that originate
outside Australia, but this is something of a special case,
in that I've been (slightly) involved in the development.
This posting is important in North America (or just the USA?)
now, because of forthcoming changes to the Daylight Saving
Rules. I suggest that source licensees install these library
functions in libc as soon as possible, then recompile everything
that uses localtime() or ctime(). You should never need to go
through that again! (Later versions of this code will likely be
available, but they should merely add functionality for new
programs, old ones compiled with this release should continue
If you have only a binary licence, you should insist that your
vendor install this code into its standard release ASAP, and
send you an update distribution. In the meantime, you could
install this in your libc.a, and have any sources that you
do compile show the time correctly. This is probably not
a real good idea though.
It is possible to install this code in a separate library (in
fact, that's how it is distributed - as the details of exactly
how to update libc.a are too variable to include here), and
then explicitly reference it on all compilations that need
any of the time functions.
There are a number of compilation options, described in the
Makefile (be sure to read that before compiling). I suggest
that you define KRE_COMPAT (yes, that's me..) and STD_INSPIRED.
If you want compatibility with some of the less broken parts of
the time implementations in Sys V, or BSD releases, you can also
define USG_COMPAT or BSD_COMPAT respectively. Finally, TZA_COMPAT
will give Vol 4 "settz" release timezone name scheme compatability.
You get tzname regardless of the setting of USG_COMPAT. Having
it included this way is an arguable benefit, it might remove itself
into the USG_COMPAT version in later releases.
One program that will cause some problems in compiling, is
date(1). The date patches posted in Vol 6 Issue 12 should help
here (you will need TZA_COMPAT, and BSD_COMPAT on BSD systems).
A new (public domain) version of date(1) is expected soon.
It will use the STD_INSPIRED functions included here, so if
you plan on using that when it appears, define STD_INSPIRED now.
Problems: With BSD_COMPAT ctime.c will become an empty file.
Without STD_INSPIRED timemk.c will become an empty file.
In general this is OK (the compiler doesn't mind), however
some versions of ranlib(1) simply can't deal with this.
Defining STD_INSPIRED will will fix timemk.c. ctime.c on
BSD systems is harder. If you are going to install this in
libc.a, then best if to remove the #ifndef/#endif that surround
ctime.c, and the duplicate version of ctime (in #ifdef BSD_COMPAT)
in localtime.c. The problem that is supposed to circumvent
will not occur in that case. If you want to keep these functions
in libz.a then easiest is probably to add some nonsense declaration
to ctime.c (outside the ifdefs) so that the file is not empty.
Finally, you should be aware that this code is designed to work
correctly (without changes) regardless of whether time_t is a
signed or unsigned type, and however many bits it contains
(withing reason), provided only that it is a standard arithmetic
type (not an array or struct). The compiled timezone files
produced are host independant (except unfortunately assume that
time_t's are 4 bytes long) - the same compiled files can be used
from a SUN or a Vax (assuming some remote file system to access
Vendors: you are expected to provide at least binaries of zic
and zdump, as well as the library functions of course, and the
sources of the time data files in any release of this code.
Providing sources of all this would be an entirely reasonable
thing to do.
So ends what is probably the longest moderator's note in the
history of mod.sources. ... kre ]