Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3139 closed Bug (No Bug)

FileGetTime out by exactly one hour.

Reported by: corz Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: FileGetTime, 1 hour, daylight saving Cc:


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)

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. (I have no earlier installs available).

;o) Cor

Original post here:

Attachments (0)

Change History (5)

comment:1 Changed 8 years ago by BrewManNH

  • Resolution set to No Bug
  • Status changed from new to closed

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

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

comment:2 Changed 8 years ago by 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!

comment:3 Changed 8 years ago by 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

comment:4 Changed 8 years ago by anonymous

Ignore the variable names! Brainfart. ;o)

comment:5 Changed 8 years ago by 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.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.