andy@piziali.lonestar.org (Andy Piziali) (04/10/91)
Israel, thank you for the detailed explanation of how UNIX systems typically
track the date, time, and daylight savings time (DST). I have a related
question because my system failed to change to DST last weekend.
I am running IBM Xenix 1.0, a Microsoft Xenix 3.0 derivative, and noticed that
the kernel didn't switch to DST. I expected the "date" program to report "CDT"
because my TZ environment variable has the value "CST6CDT." A little bit of
investigation revealed that the kernal had been built with a "master" file
whose "daylight" entry was zero, indicating DST was not to be used.
I rebuilt the kernel with "daylight DSTFLAG 1" in the /usr/sys/conf/master file
and "date" still doesn't report "CDT." I verified that the kernel's dstflag
is now set using the ftime(2) system call.
My question is: are the two dates which delimit the period of the year DST is
in effect hard coded into the kernel and could these dates have differed from
the current dates at the time this Xenix was written? I believe the kernel was
last altered in 1983 or 1984. What else should I look at to find out why Xenix
is not enabling DST?
--
Home: andy@piziali.lonestar.org |
{convex,egsner,frontier,laczko}!piziali!andy ________------+------________
Office: piziali@convex.com / \
{sun,texsun,uunet}!convex!piziali *---*gwyn@smoke.brl.mil (Doug Gwyn) (04/16/91)
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.
ronald@robobar.co.uk (Ronald S H Khoo) (04/17/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: > I don't know about your system, but genuine UNIX handles such mappings > as DST entirely in user mode, What do you recommend regarding things like cron? a) run it in GMT b) run it in local standard time, ignoring daylight. c) run it in local time, restarting cron twice a year d) teach cron to notice when someone's edited /etc/TIMEZONE e) any others? I opt for c) because uucp's crontab wants to run in the same timezone as British Telecom's charging algorithm (;-) I'm not sure about d). Any good arguments for or against any or none of the above? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
urban@cbnewsl.att.com (john.urban) (04/19/91)
In article <1991Apr17.151824.8236@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes: > >> I don't know about your system, but genuine UNIX handles such mappings >> as DST entirely in user mode, > >What do you recommend regarding things like cron? > > a) run it in GMT > b) run it in local standard time, ignoring daylight. > c) run it in local time, restarting cron twice a year > d) teach cron to notice when someone's edited /etc/TIMEZONE > e) any others? > >I opt for c) because uucp's crontab wants to run in the same timezone >as British Telecom's charging algorithm (;-) I'm not sure about d). >Any good arguments for or against any or none of the above? >-- >Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H) I vote for semi-d. Teach cron to notice when the change from Standard Time to Daylight Time occurs (or visa versa) and adjust cron's internal time so that jobs running at 23:45 (e.g. uucp's nightly jobs) continue to run at 23:45 and not 00:45 or 22:45 after the switch. NOTE: things will straight out once date XXX (where XXX is the current time) is run. Sincerely, John Ben Urban
gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)
In article <1991Apr17.151824.8236@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >What do you recommend regarding things like cron? I would want "cron", which typically runs for a LONG time, to apply the proper conversion rules to map the kernel's internal time (which is timezone-independent) to local time, to which the crontab refers. The mapping rules in general call for allowance for extra hours during DST, etc. These are part of the rules and should be applied.
guy@auspex.auspex.com (Guy Harris) (04/21/91)
>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. S5R4 includes the Olson implementation (as well as the kludgier stuff, for backwads-compatibility and, alas, POSIX compatibility); I don't know how heavily they advertise that fact, or support it in any whizzo system administration front-end (e.g., they may tell you to set TZ up as "EST5EDT" or some horrible POSIX-style "include the rules in the string" setting, rather than as "US/Eastern").
guy@auspex.auspex.com (Guy Harris) (04/21/91)
>> I don't know about your system, but genuine UNIX handles such mappings >> as DST entirely in user mode, > >What do you recommend regarding things like cron? Well, I'm not sure what your question has to do with Doug's statement, but: > a) run it in GMT > b) run it in local standard time, ignoring daylight. > c) run it in local time, restarting cron twice a year > d) teach cron to notice when someone's edited /etc/TIMEZONE > e) any others? "cron" should run in whatever time zone your "crontab" entries are. E.g., if you have an entry starting with "30 19 * * *": if you want that entry to be run at 19:30 GMT, run "cron" in GMT; if you want it to be run at 19:30 local standard time, ignoring daylight, run it in local standard time, ignoring daylight; if you want it to be run at 19:30 local time, run it in local time. If your system has a reasonable (i.e., Arthur Olson-style) time zone implementation, if you run it in local time, you don't need to restart it unless your government decides to muck with the daylight savings time rules. If your system isn't quite so reasonable, you may have to restart it at other times. >I opt for c) because uucp's crontab wants to run in the same timezone >as British Telecom's charging algorithm (;-) I'm not sure about d). >Any good arguments for or against any or none of the above? See above.