cyrill Sun Apr 10 06:49:16 1988 (04/10/88)
Reply direct to 'reo!root by mail as he doesn't get news.
From reo!root Sat Apr 9 15:23:23 1988
Received: by scicom.alphacdc.com (smail2.5)
id AA08815; 9 Apr 88 15:23:12 MST (Sat)
To: cyrill
Subject: Time on Tandy 3.2
Date: Sat Apr 9 15:05:48 1988
The advent of Daylight Savings Time this past week has brought out
an appearent bug in either XENIX 3.2 or MBASIC for the Tandy 16/6000.
Both products are from Microsoft. The "bug" is as follows:
1. uucp still executes its scheduled calls according to crontab
entries, using Daylight time. However, when it logs these, and all
incoming calls, it logs them in STANDARD time (without an xST suffix).
2. When BASIC reads the time, such as in "PRINT TIME$", the time
returned is, again, STANDARD time, not daylight. I do not remember
this problem occurring in previous years, under different versions
of XENIX.
Has anyone else encountered this, and is there a fix available?
The one in uucp is minor, but BASIC programs that test the time
before executing a function can be adversely affected by the
second.
Richard E. Oakes
USPS: 602 Dawson Street CompuServe: 70475,333
Aurora, Colorado 80011-6907
UUCP: {boulder, ncar, nbires, isis}!scicom!reo!rick
root@mjbtn.UUCP (Mark J. Bailey) (04/13/88)
In article <1618@scicom.alphacdc.com>, cyrill Sun Apr 10 06:49:16 1988 writes: > > 1. uucp still executes its scheduled calls according to crontab > entries, using Daylight time. However, when it logs these, and all > incoming calls, it logs them in STANDARD time (without an xST suffix). > > 2. When BASIC reads the time, such as in "PRINT TIME$", the time > returned is, again, STANDARD time, not daylight. I do not remember > this problem occurring in previous years, under different versions > of XENIX. When Tandy released 3.2, they had compiled the new Daylight Savings Time change period into the "basic system" code. This is why your system clock changed appropriately. However, other programs like MBASIC and uucp are not part of the "core release" and have not been modified. You will have to ask Tandy about MBASIC as it is a separate package. When the 3.2 release of their development system (which usually follows two to three months after a release of a "core" upgrade), they will have supposedly fixed the CDT/CST problems with uucp, at, and any other programs that ordinarily come with the Xenix Development System. Hope this helps. Mark. -- Mark J. Bailey _____________________________________________________ _________________\ _____| > @ Nashville Knoxville _/ / + ____'' > Jackson + <*> MURFREESBORO _/ / "From the Heart of Middle Tennessee!" ___> > + Memphis Chattanooga _< <______________________________________________+_______/ JobSoft UUCP: ...!{ihnp4,cbosgd,mit-eddie}!killer!mjbtn!root Design & Development Co FIDO: Mark Bailey at Net/Node 1:116/12 Murfreesboro, TN USA
paul@devon.UUCP (Paul Sutcliffe Jr.) (04/14/88)
In article <1618@scicom.alphacdc.com> cyrill Sun Apr 10 06:49:16 1988 writes: +--------- | Reply direct to 'reo!root by mail as he doesn't get news. +--------- Okay, I did. But I decided to post this too, since others may benefit. +--------- | The advent of Daylight Savings Time this past week has brought out | an appearent bug in either XENIX 3.2 or MBASIC for the Tandy 16/6000. | Both products are from Microsoft. The "bug" is as follows: | | 1. uucp still executes its scheduled calls according to crontab | entries, using Daylight time. However, when it logs these, and all | incoming calls, it logs them in STANDARD time (without an xST suffix). | | 2. When BASIC reads the time, such as in "PRINT TIME$", the time | returned is, again, STANDARD time, not daylight. I do not remember | this problem occurring in previous years, under different versions | of XENIX. +--------- The 3.2 runtime system (the kernel and all utilities supplied with it) were created with a new (improved!) ctime(S) call that knows about the recent changes in DST rules. In fact, the ruleset is in a text file called /etc/usa.dst and can be modified and recompiled into the kernel when necessary (smart move Tandy!). However the 3.0 development system stuff (uucp, etc) are using the old ctime() that won't acknowledge the DST change until the end of this month. The case you state in (1) is caused by the fact that cron knows the new rules (it comes with 3.2 runtime), so it invokes commands at the right time, but uucp doesn't, so its log entries are off by 1 hour. My temporary fix to this (until 3.2 development system is released) was to run /etc/tz. Answer the questions this way: Does daylight savings time apply at your location? no Are you in north america? no What is the name of your timezone? EDT How many hours west of GMT are you? 4 This has the effect of changing TZ to say "TZ=EDT4" instead of "TZ=EST5EDT" and then updating the appropriate files (/etc/rc, /etc/default/login and others). This technique was discussed last year in various newsgroups. - paul -- Paul Sutcliffe, Jr. +----------------------+ | THINK ... | UUCP (smart): paul@devon.UUCP | or THWIM | UUCP (dumb): ...rutgers!bpa!vu-vlsi!devon!paul +----------------------+
uhclem@trsvax.UUCP (04/25/88)
<> B>The advent of Daylight Savings Time this past week has brought out B>an appearent bug in either XENIX 3.2 or MBASIC for the Tandy 16/6000. B>Both products are from Microsoft. The "bug" is as follows: The problem is not with XENIX 3.2 but instead with the way that XENIX/UNIX handles date conversions from the internal format. Instead of putting a system call in the kernel like other operating systems, UNIX/XENIX requires that each program carry the algorithms to do the job. They are in one of the libraries that a program was linked with. When the government changed the way DST worked, every program would have to be relinked with the newer library to work right. Many other versions of XENIX/UNIX on the market are having similar or worse problems depending on how many programs on that system contain the new DST rules. Full system releases made after Jan 1987 generally fix the problem except for applications. In XENIX 3.2, the routines that manage date conversions now examine a file for the rules on how to handle DST. So if the U.S. government changes the fall date (which is expected), or makes any other change, a change to the rule-file will fix handling for all programs. This also works nice if you happen to live in a country that is 15 minutes + solar time or some other unusual local time convention. The files in the development system that utilize time will be replaced in the 3.2 development system upgrade when it becomes available. Other programs like MBASIC will likely be stuck since Microsoft has dropped support of all their 68000-based products except Multiplan. (Microsoft announced this in late 1985.) You might get the vendor of some products to provide a corrected version by dealing with them directly, but they will be unable to help until the development system is available to them so that they can get the new libraries. <This information is provided by an individual and is not nor should be construed as being provided by Radio Shack or Tandy Corp. Radio Shack/Tandy Corp has no obligation to support the information provided in any way. Since you can't spell the processors' name backwards and get "Letni", they probably don't care anyway.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem K:"We are the knights who say.... 'Letni'!" A:"No, not the knights who say 'Letni'!" K:"The same!" G:"Who are they?" K:"We are the keepers of the sacred words.... 'Letni', 'mostly-upward-compatible' and 'fixed-in-the-next-mask'! A:"Those who hear them seldom write reasonable code again!" K:"The knights who say 'Letni'... demand a sacrifice!" A:"Well what is it you want?" K:"We want..... A Segment Register!!" A:"A what?" K:"Letni! Letni! Letni!" A:"Please... no more! We will find you a segment register." K:"One that looks nice." A:"Yes." K:"And holds 32 bits but only uses 16." A:"Of course." and on and on...