teb@sequoia.UUCP (Thomas E. Bernhard) (05/02/89)
I have noticed that the timestamps on files I created before daylight savings came into effect now show the times to be 1 hour off. For example I created a file named "demo" and its timestamp is 3-08-89 4:57p. Now when I do a dir on that file, it has a timestamp of 3-08-89 5:57p. My setup is just like the nfsconf says it should be. It sets TZ = CST6CDT. On the file server, unix says the timestamp of the same file is 16:57 which is the correct time. After further testing I believe that PCNFS 3.0 does the TZ stuff wrong. Does anyone know of a work around? Tom Bernhard execu!teb@cs.utexas.edu Execucom Systems (512) 346-4980 Austin, Texas
billc@mirror.UUCP (Bill Callahan) (05/02/89)
> > I have noticed that the timestamps on files I created before daylight savings > came into effect now show the times to be 1 hour off. For example I created > a file named "demo" and its timestamp is 3-08-89 4:57p. Now when I do > a dir on that file, it has a timestamp of 3-08-89 5:57p. My setup is just > like the nfsconf says it should be. It sets TZ = CST6CDT. > > On the file server, unix says the timestamp of the same file is 16:57 which is > the correct time. After further testing I believe that PCNFS 3.0 does the > TZ stuff wrong. Does anyone know of a work around? > > > Tom Bernhard execu!teb@cs.utexas.edu > Execucom Systems (512) 346-4980 > Austin, Texas Yes, we have seen this bug, too. Let me explain it. On the unix system, times are stored in GMT. They show up in local time in a directory listing due to a runtime conversion. On a PC, times are stored by local time, and ordinarily, no conversion at display time takes place. PC NFS, therefore, has to handle these two different systems. It does it by emulating the unix method, i.e., it stores times in GMT and does a conversion for a directory listing. When the NFS initilization programs are run, usually in the autoexec, they look at the TZ variable to determine what time zone the PC is in, and whether the zone has daylight savings time. It has an alogorithm to determine whether are not daylight savings time is in effect, based on date and the rules for when the times change. The problem is due to the fact that Congress changed the rules. Daylight savings time occurs a few weeks earlier than it used to. Unfortunately, the software doesn't know this. Sun says that they are aware of this bug, and will fix it in future releases. They said to just wait until the old switch date comes by (it has, by the way) and the problem will fix itself. If this bug bites you again, you can do a kludgey work around for the periods between the old switch date and the new one. Simply change the TZ variable to a different time zone. We change ours (here on the East Coast) from EST5EDT to simply EST4, which looks silly, but worked. In fact, I could now change it back to EST5EDT, but EST4 still works, since apparently if you take off the "EDT" at the end, it won't do the daylight savings time conversion at all. (I know that the "EST" at the beginning should probably change too, but Sun doesn't list the three letter sequence for the time zone east of the East Coast, but it seems to work anyway.) Hope this works for you. BTW, I'm not sure if Congress also changed the rules for the fall, but if so, this bug will be back again soon. --------------------------------------------------------------------------- Bill Callahan billc@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc Mirror Systems 2067 Massachusetts Ave. 617\661-0777 x149 Cambridge, MA 02140
kevin@sol.UUCP (Kevin Kelleher) (05/04/89)
Tom Bernhard wrote: >I have noticed that the timestamps on files I created before daylight savings >came into effect now show the times to be 1 hour off. For example I created >a file named "demo" and its timestamp is 3-08-89 4:57p. Now when I do >a dir on that file, it has a timestamp of 3-08-89 5:57p. My setup is just >like the nfsconf says it should be. It sets TZ = CST6CDT. > >On the file server, unix says the timestamp of the same file is 16:57 which is >the correct time. After further testing I believe that PCNFS 3.0 does the >TZ stuff wrong. Does anyone know of a work around? I discovered the same bug and reported it to Sun, they said the problem was that the compiler used to compile PC-NFS didn't know about congress's most recent change to the daylight savings time rules and would go away when the compiler thought daylight savings time was going to start. I fix for next year is supposed to be in the next release. Note: version 2.0 has the same bug.