Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: The switch to daylight savings time
Keywords: CMOS, date, DST, setclock, time, TZ, Xenix 3.0
Message-ID: <15842@smoke.brl.mil>
Date: 16 Apr 91 01:14:45 GMT
References: <9@phlpa.UUCP> <PINKAS.91Apr9141415@st860.intel.com> <1991Apr10.114836.10816@convex.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16

In article <1991Apr10.114836.10816@convex.com> andy@piziali.lonestar.org (Andy Piziali) writes:
>What else should I look at to find out why Xenix is not enabling DST?

I don't know about your system, but genuine UNIX handles such mappings
as DST entirely in user mode, not in the kernel (which maintains time
in terms of seconds elapsed since the "epoch").  Probably the C library
functions such as ctime() that are used by your system utilities have
an inappropriate hard-coded DST switchover date embedded in them, in
which case the only solution is to fix the library and relink the
utilities (assuming they are not binding dynamically at load time).
Arthur David Olson a couple of years ago posted an implementation of
the standard time conversion functions that was driven by external
table files, which allow for easy incorporation of new time zone rules.
For unknown reasons, AT&T appear to have settles on a kludgier approach
for their implementations.  If you can use the ADO code, your troubles
should be over.