Click for MacWindows home
Updated April 22, 2003
Send us your comments.
Problems and solutions for issues with modification date and times
Other Windows NT/2000 Tips pages at MacWindows:
NT Server Tips
April 4, 2000 --
We have a Windows 2000 machine that servers up files to a variety of Macs. The Windows 2000 machine also runs Adobe Distiller - we have a hot folder setup to RIP .ps into .pdf.
We noticed today that the files generated by Distiller are showing up under OS9 machines with a random hour offset on the time stamps (modified and created.) And before you ask, I double-checked to make sure all the Mac clients were using the same time zone (Central), the same time (manually synched to an online time server) and are observing daylight savings time. For example, a file with a modified time as 3:37pm appears as 6:37pm on one OS9 machine, it appears as 2:37pm on another OS9 machine, a third OS9 machine shows the time correctly as 3:37pm, and 3 separate OS 8.6 machines show the time correctly.
April 6, 2000 --
Many readers have written in to say that they've seen the SFM time stamp problem when the time zones are set differently on computers. However, Rob Simons says that all his Macs are set to the same time zone, but didn't say if the Windows 2000 Server was synched. (Rich Pape notes that Microsoft and Apple both default to the Pacific Time zone.)
Thomas Clifford is experiencing differences of half an hour on different Macs for the same file with Win NT 4.0 SP5. (See below.)
Both Simons and Clifford are having their problems with Macs running OS 9, but John Stone is having another time-stamp related problem with OS 8.5-8.6 Macs, and not OS 9. (Stone is also running NT 4.0 SP5). Stone reports that when Daylight saving Time changes in April and October, NT changes last modification dates of all the files.
Half an hour differences
April 6, 2000
We are experiencing a painful problem with time stamp shift with Win NT 4.0 SP5. I am not sure what the heck has happened, but I have one volume SFM volume that one machines reports a file was modified at 9:13 am and a machine right next to it reports the time at 10:13 am. Another weird thing is a third machine is reporting the time of the files at exactly half and hour later 10:43 am
Both machines are running Mac OS 9 and are time synched to the Apple time.
I am going to delete the SFM partition and recreate it and we'll see from there.
Thomas Clifford then fixed his problem:
All the Macs reporting the issue were running Mac OS 9 and were set to the same Central Time zone. After our last email I went and deleted the SFM share from the NT Server, rebooted the machine and then re-created the SFM share, allowing the machine to reindex all the files. This fixed the issue. No more troubles here.
April 6, 2000
The department that I work in uses Macintosh clients on a Windows NT 4 Service Pack 5 network. All of the Macs are running Mac OS 8.5 or higher, but not OS 9. When the Daylight Saving Time changes in April and October, ALL of our files that reside on the NT servers have their last modification dates changed by the NT system. For instance, when we create or modify a file and save it back on the server the modified date might show 11/21/98 @ 1:03:10 UAM but when the daylight savings time changes, the file then shows a modified date of 11/21/98 @ 2:03:10 UAM in the Spring. From what I have read at the Microsoft site, this is normal for NT since it bases all file times on GMT and then adds or subtracts the number of hours required for your time zone and I don't think the Macintosh does this (I maybe wrong though).
This creates a huge mess for the Mac clients since all of the photos that we use in our QuarkXPress layouts show up as having been modified even though they have NOT been modified, at least by the Mac clients. This is a huge flaw in the NT-Mac communication at least in my company. I am surprised that I have not heard a lot of complaining from the Mac community since there are a lot of companies that use NT servers and Mac clients.
April 11, 2000
I have a fix for the modification dates bug. When I looked into this, I found an article on Apple's TIL which explained this as a "feature" of AFP (apple filing protocol). I call it engineers getting too clever.
Apparently the date modified of a file on an AFP volume is stored as an offset from Jan 1, 2000, 12:00 a.m. in a particular time zone, in positive or negative seconds. That time is delivered to the Macintosh client, which adjusts that offset according to its own time-zone, and then reports an actual date and time. This makes sure that all modification times of files in different time zones show the time relative to the computer which is querying - it makes sure a file modified yesterday (yesterday according to the server's clock) reads 24 hours ago, whatever the time the particular Macintosh says. The actual date/time calculations are made with a 15 minute buffer, so that clocks that are slightly out of synch will use the same time exactly (buffered adjusted server time), so their calculations come out exactly the same.
The problem in Quark arises from Quark stamping the file placement record in the document with the actual, calculated time (not 24 hours ago, but Wednesday, April 6, at 12:21 p.m.) when the image is placed. When daylight savings hits, 24 hours ago becomes 11:21 p.m., or 1:21 p.m., preserving the offset but losing the calculated result. Quark sees that as a modified file -- it doesn't match the stored value. If people start updating images, they're stamping the files with 11:21 or 1:21 p.m., which is wrong.
Interactions around the 15 minute buffer could make a 1/2 hour difference, but I don't know how, exactly ...
The way around the hours offset is to disable daylight savings on all involved machines in order to get rid of that 1-hour offset, and make absolutely sure all your time-zones are correct, and then manually adjust and synchronize the clocks (use a tool that can change clocks on multiple computers, like ANAT) before people start working after a daylight savings change. If they are working while you're adjusting, they have to disconnect and reconnect the server volumes with the important dates. It's a pain, but its the only way I've found.
April 19, 2002
The issue is that this time stamp problem exists on Win 2000 Pro even without a Mac interface. Furthermore, this problem seems to affect binaries and executables and not text files [as much]. I have asked for advice and I cannot get an answer from Microsoft.
Tip: Daylight Savings, NT time stamps, and QuarkXPress.
April 13, 2000 -- Eric Anondson came across a Quark TechNote (last updated in April '97) concerning the time stamp issue of Windows NT and clients. The article recommends time synching the clients and the NT Server. He also found a post in Quark's Forums (message #28462) concerning the Daylight Savings time stamp issue we've reported. It says in part:
If you have Quark libraries that include images stored on a Windows NT file server, you will encounter problems after the time change unless you turn off "Automatically adjust clock for daylight saving changes" on the NT Server.
Instead, manually change the time on NT Server after the time change occurs. (Use the Date/Time icon in the Control Panel.)
The message goes on to explain why this happens. It has to do with how Windows NT handles the Daylight Savings time change and how it affects Quark Xpress:
Just before 2 a.m. on such dates, Windows NT modifies the time stamp of every item on the server, moving each one hour back (spring) or ahead (fall) -- the opposite of what you would expect.
Then, when the time switches from 1:59:59 to 3:00 (spring) or 1:59:59 to 1:00 (fall), Windows NT adds an hour (spring) or subtracts one (fall), putting the time stamp back to what it originally was.
The time stamp LOOKS the same as before the time change, but QuarkXPress accurately detects that the time stamp was modified. As a result, if you try to use an item in a Quark library that contains an image stored on the NT server, Quark will display a message telling you it was modified and require you to update it.
Quark tech support agreed with this approach (message #28475).
April 11, 2000
I have experienced similar cases where the create date/modify date for a file on our new NT server was off by exactly an hour. I had one computer off by exactly 30 minutes. I tracked the problem down to a bad AppleShare Prep file in the preferences. Delete that file. Then reconnect to the server and all is fine.
I believe this file may get "confused" if you first connect to an NT server, and then go back to your Mac and change your time zone, or make a change to the "Daylight Savings Time" checkbox on the Date & Time control panel.
We have seen at times where the server is in a different time zone and files stored on the server get changed to different 24 hr. clock times for modification (i.e. backup/archive bit flags, read only, permissions, etc.).
January 29, 2001
Regarding the timestamp problem (Daylight savings, Mac clients/NT server, and Quark)...
You can add Extensis Portfolio (v4) to the list of affected applications. At a client location the other day this issue came up, after some discussion it was apparent that the same problem was hitting them both in Portfolio (when updating items conditionally) and in Quark (images showing as "modified"). I have not yet checked this issue in version 5.
June 10, 2002 -- Michael Modisett reports having this same problem with Extensis Portfolio 4 Modisett was wondering if the issue also occurs with Extensis Portfolio 6.0. If you can shed some light on the issue, please let us know.
April 10, 2003
Pasquale Camporeale sent in a solution for the problem with Windows NT Server and daylight savings time:
I've been working with Retrospect from Dantz on a Mac backing up NT and 2000 boxes that run Mac Services. For about 5 years now I have been going crazy over Daylight Savings Time shift as everyone else on this posting has also.
So I decided to make my own tests.
My conclusion is a fix as a 2 step process:
1) The Mac client and the Win Server must have Automatically adjust for Daylight Savings = OFF/not selected/unchecked/false/don't click here
2) Then manually change the Mac Client and the Win Server Date/Time controls to match each other when Daylight savings occur.
* Note: this must be done with no shares mounted on the Mac's desktop.
If you've tried this approach, let us know what you think.
April 11, 2003
There is a demonstrated bug with NTFS file systems and daylight savings time. It appears that Win NT stores files using a LOCAL timestamp, and then tries to translate it back to GMT. When DST changes occur, the computation gets screwed up, and all file dates are one hour off.
During earlier beta testing of a Windows mail server software product called MDaemon (by Alt-N software), the developers found that Daylight Savings Time bug in Windows and had a really difficult time working around it. I'm not sure how they managed to work around it, but I haven't seen anyone report problems with it during the recent time change.
So far, Microsoft has not released any kind of patch or fix for the problem, that I'm aware of.
April 14, 2003
Dedrick Allen says the problem also occurs with Windows 2000 Server, particularly with Quark XPress. Allen passes along a recommendation from Quark to deal with problem:
This bug also exists in Windows 2000. Quark users who work off NT/2K Mac volumes are probably VERY aware of this because whenever DST rolls around and the servers are set to Autoupdate DST, Quark users have to update all their images etc... that are on Quark pages/documents because Quark thinks they have all been modified. Quark has recommended turning off the Autoupdate for DST feature in NT/2K for some time and it does fix the problem UNLESS your in a NT/2K domain. All your servers sync to the domain controller and if you turn off Autoupdate for DST your servers will be 1 hour behind. I have been battling this, THIS week as a matter of fact. For those who user authentication such as Kerberos that use time as part of the authentication, this will not work because all the servers and clients must have the correct/same time. But if your not in a domain Pasquale Camporeale's and Quarks fix will work for you.
No luck with fixes
April 22, 2003
We are experiencing the appointment recurring time shift since daylight saving time came back. Multiple users who had recurring appointments now have them show up in calendar view as being one hour off.
We have reset OS prefs as well as reinstall. The only fix so far is correcting them via Outlook on a PC or Citrix. Changing them manually on the Mac does not always correct them.