RRelay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!gatech!lll-lcc!seismo! munnari!sources-request From: sources-requ...@munnari.UUCP Newsgroups: mod.sources Subject: v08i085: Public Domain (Table Driven) ``localtime'', Part01/03 Message-ID: <1435@munnari.oz> Date: Sat, 28-Feb-87 06:49:08 EST Article-I.D.: munnari.1435 Posted: Sat Feb 28 06:49:08 1987 Date-Received: Sun, 1-Mar-87 13:52:19 EST Sender: k...@munnari.oz Lines: 1058 Approved: k...@munnari.oz.au Submitted by: Arthur David Olson <a...@elsie.UUCP> Mod.sources: Volume 8, Issue 85 Archive-name: pd-localtime/Part01 [ 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 to work). 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 them). 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 ] Code