davis@MASIG1.OCEAN.FSU.EDU (Alan Davis) (04/04/89)
To other 3xxx owners or someone at SGI, is there a way to make the system
recognize that daylight savings time now starts in the beginning of April
rather than at the end of the month. We have the included the EDT field to
TZ, but the system doesn't recognize it till the old date. I noticed that
this has been fixed on the Personal Iris. What about us oldtimers?
--
Alan Davis |
Mesoscale Air-Sea Interaction Group | TCP/IP davis@masig1.ocean.fsu.edu
Florida State University | (128.186.3.1)
435 OSB Meteorology Annex | SPAN scri::"davis@masig1.ocean.fsu.edu"
Tallahassee, FL 32306-3041 | BITNET davis%masig1.ocean.fsu.edu@cunyvm
(904) 644-3798 |
_______________________________________________________________________________blbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) (04/04/89)
I have been told that the daylight savings time code is hardwired into the kernal (real stupid place to put it). The question of getting this changed is asked every time we toggle between standard and savings time. So far I haven't heard of a solution yet. They should get this information from a file that can be easily changed, like the holidays file or something similar. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
vjs@rhyolite.SGI.COM (Vernon Schryver) (04/05/89)
The timezone is not wired into any IRIS kernel. It may be in some others, but all IRIS's all run flavors of System V. (Forget the V-kernel, and the old 4.2 experiments you may have heard of.) Remember that in SV, ctime(3) uses the TZ environment variable (or TIMEZONE in SVR3) to know how to convert from the GMT maintained in the kernel to whatever you want to see. To fix time on an IRIS 3000 running 3.6, you can: 1) change the date on your machine. You will confuse your uucp and sendmail neighbors, but if you are not running timed(1m), nntp, timeslave(1m) et al, this is probably simplest. You will have to ignore the '[ECMP]ST' in date strings. You will also have to change the date again in a few weeks. If you use NFS and make(1) for software development, simply changing the date will cause some little confusion, unless all machine change it similarly. To everyone inside SGI: DO NOT DO THIS, USE #2, #3, or #4 BELOW! 2) save and edit /etc/TZ, and reboot. For example, the string 'PDT7' solves the symptom on the west coast. You will need to remember to restore the old contents of /etc/TZ after May 1, and before fall. You must reboot to get everything using the new envirnment variable. 3) don't worry, be happy, and use a real clock for the rest of the month. This is probably the best "solution." 4) get rid of this "day light savings" silliness, and use UTC/GMT. You will be able to babble 'zulu' and other impressive things. Vernon Schryver Silicon Graphics vjs@sgi.com
djlinse@phoenix.Princeton.EDU (Dennis Linse) (04/05/89)
In article <29974@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes:
->
-> [Offers some useful comments including ... ]
->
->The timezone is not wired into any IRIS kernel. ...
->
->To fix time on an IRIS 3000 running 3.6, you can:
->
->1) change the date on your machine.
-> You will have to ignore the '[ECMP]ST' in date strings. You will
-> also have to change the date again in a few weeks.
->
->2) save and edit /etc/TZ, and reboot. For example, the string 'PDT7'
->
->3) don't worry, be happy, and use a real clock for the rest of the month.
-> This is probably the best "solution."
->
->4) get rid of this "day light savings" silliness, and use UTC/GMT.
->
->Vernon Schryver
->Silicon Graphics
->vjs@sgi.com
While all of these are viable alternatives, I thought that the original
question was more aimed at the reason that one must ignore the
'[ECMP]ST' when it is actually '[ECMP]DT'. Where is the code that
magically changes for standard time to daylight savings time. It is
hinted in at least one manual page (ctime?) that there is a way to set
up a new table to adjust for different days to change to daylight
savings time. It even mentions doing something special for 1974 and
1975. (I know neither why this is important nor why one needs this, or
does someone out there run their machine on 1974 time :-)
Dennis
djlinse@phoenix.princeton.edu
--
Found at the top of a looonnng homework assignment:
"Activity is the only road to knowledge" G.B. Shawblbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) (04/05/89)
Nothing you said is a "solution", only a patch. Can we expect SGI to FIX this BUG in the system? Where are the daylight savings change over dates set? -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
vjs@rhyolite.SGI.COM (Vernon Schryver) (04/06/89)
In article <7587@phoenix.Princeton.EDU>, djlinse@phoenix.Princeton.EDU (Dennis Linse) writes: > > ... Where is the code that > magically changes for standard time to daylight savings time. > > djlinse@phoenix.princeton.edu The old ctime(3) code has a compiled-in table. There is at least two more or less public domain versions of ctime(3) which use various methods to convert time to an ASCII string, including worrying about timezones and daylight savings. You could write your own. That will not help very much on a [123]000 unless you have the source to things such as ls(1), date(1), sendmail, [mM]ail, and csh(1), all of which are linked with the previous version of ctime. At least the SVR3.2 based 4D's have the new style TZ environment variable, which lets you set things to your government's heart's content. (Guy Harris has reminded me that it was always the TZ environment variable. Only the file name changed in SVR3.) Vernon Schryver Silicon Graphics vjs@sgi.com