🚀 go-pugleaf

On Mon, 05 Apr 2004 11:13:20 -0700, Bob Gonder wrote:

> That's what I thought, but if I save it, as is, and later compare it
> with itself, it's different.?

It shouldn't be OTOH it depends how you are doing the comparison.

> Unless CompareFileTime is somehow changing things?

I'd hope not but could CompareFileTime allow for local time? Surely not. In
any case you can compare FileTimes directly as they're just 64bit numbers.

> So you're saying that FindFirstFile doesn't return UTC? That Local
> time affects the returned value?

No, it returns UTC.

Okay this is getting confusing so here's my description of how I think you
could get a problem. Sorry if I'm telling you something you already know
but in these situations redescribing the problem can help clarify things :)

You execute a FindFirstFile and use FileTimeToLocalTime to convert it into
local time. You store the result in a database. Next day is the start of
DST. If you repeat the FindFirstFile and FileTimeToLocalTime conversion
then compare with the database there'll be a mismatch.

This is not because the time stored in the file system has changed but is
because FileTimeToLocalTime is returning a different result.

The mistake would be performing the conversion to local time before storing
the value in the database. Conversion to local time should occur as a final
step prior to displaying a date/time and conversion to file time should
occur immediately you receive a date/time from an external source.

> But, also what I don't get
> April 3, 10:15  doesn't change to 
> April 3,  9:15 just because this is April 5

That depends on context. From a user's POV it does change. To see why you
need to consider a multi-national company. If you are all sharing documents
(and you might be) then you need date/times to be displayed locally. I need
to know that Fred in the US office was working on our joint document at
nine o'clock in the evening. Not everywhere has the concept of DST and so
DST needs to be added into that equation. Fred needs to know that suddenly
I'm working on documents an hour earlier than last week.

But of course Fred needs times that make sense to him so hence you need a
conversion process that can take a fixed time and mangle it to produce the
current local equivalent.

If you created a document at 9:15am last Friday then today Explorer will
show the creation time as 8:15am. The date/time as stored on the disk is
unchanged but Explorer has performed a conversion by calling
FileTimeToLocalTime. A program that never used FileTimeToLocal time would
not see a difference.

If you want real problems though..

We write forensic investigation and data recovery software. We sell and use
the results worldwide. Modern file systems store their times in UTC, older
ones (including Unix) store them in local times. We had one case where a
seizure in this country included some old kit from a US office that had
been shut down. Some of it was Unix, some of it Windows.

You want confusing? Try a meeting with investigators, barristers and a
couple of put upon developers :) As I recall we didn't even get invited to
the free lunch :(
-- 
Andrue Cope
[Bicester UK]