FileGetTime out by exactly one hour.

[corz]

I have a regular file, a movie. In Windows (8.1 x64) properties dialog, it states the modification time is:

27 ‎December ‎2014, ‏‎21:53:35

This is correct. I have a record of this information elsewhere, which we will be referring to. If I run this code:

$ftime = FileGetTime($file)
SomePrintArrayFunction($ftime)

I get:

[0] : 2014
[1] : 12
[2] : 27
[3] : 22
[4] : 53
[5] : 35

Precisely one hour later than the correct time.

My current locale is United Kingdom, and we are currently experiencing "British Summer Time", which is a "Daylight Saving Time", though this should have no effect on the modification time of the file, which is December.

Because of what quacks like a bug, when my program examines this file's modification date, it sees that it is one hour older than its corresponding record (which is correct), and so considers the file modified, which it isn't, as reported by Windows Explorer et al (and UNIX.

AutoIt seems to be adding an arbitrary hour to its time output because we are inside British Summer Time. But that's just a hunch.

I've since got bug reports myself about this, all from users who are also inside "daylight saving time".

I can reproduced this on AutoIt v3.3.12.0 - v3.3.12.0.15 (I have no earlier installs available).

;o) Cor

Original post here: ​https://www.autoitscript.com/forum/topic/173666-is-this-a-bug/

[BrewManNH]

It's not a bug in AutoIt, it's how the Windows API for file times works.

​https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Windows files times are in UTC and then adjusted for the time zone you're in, UTC isn't affected by daylight savings time.

[anonymous]

Some feedback about this in the forum would have been better, of course, but I've been waiting since July for that.

I read the document you linked to. It seems to say that AutoIt is incorrectly retrieving the modification date, not taking into account local daylight saving time. I would concur. This is commonly known as a "bug".

If you are telling me that *I* am doing something wrong and that there is another way to get the actual, correct modification time, then please share!

How will changing the status to "no bug" stop AutoIt from producing the wrong results. The modification time is incorrect. It is obviously a bug!

[anonymous]

For anyone finding this page, here is something which should be in the manual page for FileGetTime (after the big notice that AutoIt will return incorrect results if you happen to be inside daylight saving time, which should matter not one jot).

$file = "c:\path\to\some\file.ext"

; retrieve incorrect time from AutoIt..
$ftime = FileGetTime($file)

; encode this into standard time structure..
$tTime = _Date_Time_EncodeFileTime($ftime[1], $ftime[2], $ftime[0] , $ftime[3], $ftime[4], $ftime[5])

ConsoleWrite("reported time =>" & _Date_Time_FileTimeToStr($tTime) & "<=" & @LF)

; Convert "local" time/date to  UTC..
$tLocal = _Date_Time_LocalFileTimeToFileTime($tTime)

; Decode struct to string..
$uTime = _Date_Time_FileTimeToStr($tLocal)

if $do_debug = $ON then debug("uTime =>" & $uTime & "<=" , @ScriptLineNumber);debug
ConsoleWrite("uTime =>" & $uTime & "<=" & @LF) ;:debug

NOW you have the correct date/time. What a pain.

;o) Cor

[anonymous]

Ignore the variable names! Brainfart. ;o)

[jchd]

Contrary to what you claim, the correct time for a decent filesystem is UTC. Want it or not this is the only non-contradictory possible convention and this is unsurprisingly what NTFS uses.

Also your "fix" is wrong, you should be using _Date_Time_FileTimeToLocalFileTime. Can we now stop discussing this in Trac, this is definitely not the place for that. "No bug" confirmed.