rjd@occrsh.ATT.COM (04/04/88)
> >Alternatively, turn FOO(n)BAR into BAR(n)FOO, i.e. PST8PDT -> PDT8PST > >Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" WRONG. The offset will still be wrong, so if it is actually 10:00 am PDT, your incorrect change will show 9:00 am PDT, i.e. it will show PDT though it is still thinking in terms of PST, and the offset of 8 hours will still be in effect, at least until April 24, when your screw-up becomes apparant by saying that it is 10:00 am PST (when it is actually 10:00 am PDT - the time will be right, the daylight versus standard time indicator will be wrong). The routines that look at the TZ variable interpret it thus: if the format of the variable contents is three characters followed by a number, then there is NO daylight savings time offset ever to be used (do not modify the time to reflect daylight savings time), unconditionally offset the time to the specified hours off of Greenwich, and use the characters preceding the number as the characters output to indicate timezone WITH NO INTERPRETATION of the characters (i.e. it just repeats them without looking at them). If the format of the TZ variable is three characters, a number, then three more characters, then DO offset the hours one hour ahead of the specified offset during the programmed periods of the year (which are incorrect on many machines due to the recent changes), and, when not implemented, echo out the first three characters, and, when implemented, echo out the last three characters. The offset number in the middle is the number of hours off Greenwich during standard time. The ONLY correct way of doing it by only modifying the TZ enviroment variable is to change FOO(n)BAR to BAR(n-1), as was stated before.... The other ways all require changing the library routines to the new daylight savings time implementation and de-implementation dates and recompiling all programs compiled with the old, incorrect routine. Randy