🚀 go-pugleaf

Andrue Cope wrote:

>On Mon, 05 Apr 2004 11:13:20 -0700, Bob Gonder wrote:
>
>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.

Hmmm.. if( (DWORDLONG)OldTime == (DWORDLONG)ftCreationTime ) ?


>> 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 

I thought so....

>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.

I don't convert it in any way.

> You store the result in a database.

I use FileStruc.FileTime = ffb.ftCreationTime;

> 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.

Agree. That's why I don't do that.

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

Ok, but really, it shouldn't either, see later.

>The mistake would be performing the conversion to local time before storing
>the value in the database.

Yep. I don't.

> Conversion to local time should occur as a final
>step prior to displaying a date/time 

I don't even do that as the "correctness" of the UI is unimportant to
the app.

>and conversion to file time should
>occur immediately you receive a date/time from an external source.

??

>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. 

Ok....

> 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.

Ok, but...All of a sudden, Fred sees that you have _always_ been
working at 8PM. He doesn't see that you _used_ to work at 9PM.
 Heck, he even sees that his underlings at his office used to be at
work at 8am, but now they don't even get into the office until 9!
Those lazzy....

>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.

Yep, but it should also take the _date_ into consideration too. Since
date is part of FILETIME, the info is available, and
FileTimeToLocalTime should Not add DST to non-DST dates. Otherwise....

>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.

Talking of forensics.. So if I murder someone at 9am last Friday, get
to work by 10 to create a computer trail, come Monday when the cops
see me, my computer dutifully shows my 9am alibi. Thanks MS!

> A program that never used FileTimeToLocal time would
>not see a difference.

That's what's confusing.  I don't use anything other than CompareTime.

> Modern file systems store their times in UTC, older

Including Win98, right?  (This is running on a '98se box)