Can you please explain File Time Stamps to me?

[Joseph Geretz]

The code statements below are from the .NET framework using C#. However the
question I'm asking is not specific to this environment. I'm asking for help
in understanding file timestamps which are characteristic of the underlying
filesystem.

I'm getting all confused with the various types of filetimes; local and UTC
if I understand that much correctly.

FileInfo FI = new FileInfo(FileSpec);

According to my understanding, I would expect

FI.LastWriteTime.ToFileTimeUtc();
to be equal to
FI.LastWriteTimeUtc.ToFileTime();

According to my (mistaken) understanding, the first gets the local LastWrite
time and then converts it to a UTC FileTime. The second one gets the Last
write time in UTC and then simply converts it to a FileTime. So why do these
come out different?

These two I understand:

FI.LastWriteTime
FI.LastWriteTimeUtc

But these four, which use various combinations of local & UTC conversion are
a mystery to me. Since LastWriteTime can be retrieved as either
LastWriteTimeor UtcLastWriteTimeUtc Why do we need a ToFileTimeUtc at all?

FI.LastWriteTime.ToFileTime
FI.LastWriteTime.ToFileTimeUtc
FI.LastWriteTimeUtc.ToFileTime
FI.LastWriteTimeUtc.ToFileTimeUtc

Are therse two simply invalid?

FI.LastWriteTime.ToFileTimeUtc
FI.LastWriteTimeUtc.ToFileTime

Does it mean anything to pair local and Utc methods together in this manner,
or is this simply illogical?

Specifically, I need to compare the times for two files on separate servers.
I'm pulling my information via Web Services and the two servers may be in
different time zones. How can I get the last write timestamp from both files
in a unified format so that I can see which file was written to more
recently?

Thanks for your help!

- Joe Geretz -

 

[Dave August]

Joe,

It's been many years since I delved into Windows file time issues. I always
had trouble getting 'Doze to give consistent times, granted a lot was
because way back MS kept changing their idea of when the epoch started, I
remember it as being 24:00 Dec31 1972, 00:00 Jan1 1972, 24:00 Dec31, 1899,
00:00 Jan 1 1900, (and you think that the 24:00 and 00:00 would give the
same times but they didn't) and a couple of other goofy dates and times... I
know this sounds totaly gross but the only way we could reconcile things
(and we had machines running different MS OS's world wide) was to set all
machine time zones and time (including CMOS) to UTC. It was thereby
impossible for any time function from any library to give incorrect results.
BTW if you do this your times will even match a 'Nix box...

Dave