LaurentC

Reading the forum : there are many marvelous users that have made astonishing answers, samples or UDF = I'm just a welcomer 😉

Yes = the same code algorithm than _FileGetTimeDST() that I propose in my previous post, but 5 years ago : https://www.autoitscript.com/forum/topic/205935-filegettime-uses-an-improper-tzdst-shift-at-todays-date/page/2/?tab=comments#comment-1483426 I just coded, additionally, all the FileGetTime() options with the returned string for my usage @hifi55 proposes also FileSetTimeExt() ! and all explanations Nice 😃

Hi I've discovered today there was an AutoIt ticket 6 years ago ! FileGetTime out by exactly one hour : https://www.autoitscript.com/trac/autoit/ticket/3139 The ticket was classified as 'No bug' ! And I think AutoIt is right !! The FileGetTime() function is conformed to Microsoft’s implementation !!! That why I mean this is an AutoIt documentation issue (if we can say that, of course ; -) As a new user of FileGettime(), I have started a new subject, because there was no DST warning inside FileGetTime() Help that just replicates the Microsoft behavior not aligned to W10 behavior : a warning as explained in Microsoft documentation... Regards

I know, but I wanted just to notice that your Wiki entry was interesting too by itself 🙂

I thank you jchd I remember you gave us also that : Regards PS : Remind that I have never said in this post to have the intent to correct all UTC-TZ-DST cases : very hard stuff. Just to let FileGetTime() display date-time as the new W7/W10 properties window...

I shall need to become overwhelming ! 😜

Hi Melba23 I frown on post count padding too, but I'm sure you will have seen it was just 3 out of the needed count, and that I do not post empty things here 😊 in the topic or in all topics Regards

Excellent ! Yes, there are many happy philosophers here ! 😂 And $Dead = False again with Heaven ! Hey, I'm discovering I just about to go into Forum Heaven ! Members --> Active Members 20 posts : Active Members - Members with more than 20 posts have additional rights No adverts Slightly more generous attachment and PM limits Access to the Chat forum Ability to upload files to the Downloads section Yes 😀 ! See your God's men software 1.0 post now 😉

Not for newbie 😁 Sorry, there is a problem This forum is only available to those in the Active Members group. Please see this post for details. Error code: 2F173/K

I discover, not without satisfaction, that there are many philosophers on this forum: a guarantee of quality ☺️

Hi I have tried to code a kind of "UDF"... 😉 What do you think of this _FileGetTimeDST() alternative ? Regards ; ; https://www.autoitscript.com/forum/topic/205935-filegettime-uses-an-improper-tzdst-shift-at-todays-date/ ; https://docs.microsoft.com/en-us/windows/win32/sysinfo/file-times ; ; Debug à commenter pour le Build F7 d'un *.EXE ;#include "..\..\Dbug\_Dbug.au3" ; À commenter si usage de _Dbug.au3 et à décommenter pour le Build F7 d'un *.EXE... #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 #include <Constants.au3> #include <file.au3> #include <Date.au3> #include <Array.au3> _ArrayDisplay(_FileGetTimeDST("TEST 20190115_180000.txt")) MsgBox(0, "TEST 20190115_180000.txt", "Returned string = " & _FileGetTimeDST("TEST 20190115_180000.txt", 0, 1)) _ArrayDisplay(_FileGetTimeDST("TEST 20190715_180000.txt")) MsgBox(0, "TEST 20190715_180000.txt", "Returned string = " & _FileGetTimeDST("TEST 20190715_180000.txt", 0, 1)) #cs Title: _FileGetTimeDST() = FileGetTime() alternative for DST Filename: N/A = Inline code in autoitscript.com forum Description: Get file date & time taking into account the DST shift with your Windows local TZ /!\ Windows local TZ only : no use of the real geolocation information in a file as EXIF inside a photo The date & time returned are thus compliant with W7/W10 Windows File Explorer new display rule for files properties... Author: LaurentC Version: 1.0 Date: 06/06/2021 Requirements: AutoIt 3.3.14.5, Developed/Tested on W10 20H2 French Uses: Constants.au3, file.au3, Date.au3, Array.au3 Usage : _FileGetTimeDST ( filename [, option = 0 [, format = 0]] ) Parameters filename: The path to the file or directory to check option: [optional] Flag to indicate which timestamp $FT_MODIFIED (0) = Last modified (default) $FT_CREATED (1) = Created $FT_ACCESSED (2) = Last accessed Constants are defined in FileConstants.au3 format: [optional] to specify type of return $FT_ARRAY (0) = return an array (default) $FT_STRING (1) = return a string YYYYMMDDHHMMSS Constants are defined in FileConstants.au3 #ce Func _FileGetTimeDST($filename, $option = 0, $format = 0) If Not FileExists($filename) Then Return SetError(1, 0, "Unable to find file") If $option < 0 Or $option > 2 Then Return SetError(2, 0, "Bad option value") If $format < 0 Or $format > 1 Then Return SetError(3, 0, "Bad format value") Local $hFile = _WinAPI_CreateFile($filename, 2) If $hFile = 0 Then Return SetError(3, 0, "Unable to open file") Local $tFileTime = _Date_Time_GetFileTime($hFile) _WinAPI_CloseHandle($hFile) if $option = 0 Then $tFileTime = $tFileTime[2] ; Date Modified if $option = 1 Then $tFileTime = $tFileTime[0] ; Date Created if $option = 2 Then $tFileTime = $tFileTime[1] ; Date Accessed Local $localStr $localStr = _Date_Time_FileTimeToStr($tFileTime,1) ; Returns yyyy/mm/dd hh:mm:ss ;MsgBox(0, "", "_Date_Time_GetFileTime : " & $localStr) Local $tSystemTime = _Date_Time_FileTimeToSystemTime($tFileTime) $localStr = _Date_Time_SystemTimeToDateTimeStr($tSystemTime,1) ; Returns yyyy/mm/dd hh:mm:ss ;MsgBox(0, "", "_Date_Time_FileTimeToSystemTime : " & $localStr) Local $tLocalTime = _Date_Time_SystemTimeToTzSpecificLocalTime($tSystemTime) $localStr = _Date_Time_SystemTimeToDateTimeStr($tLocalTime,1) ; Returns yyyy/mm/dd hh:mm:ss ;MsgBox(0, "", "_Date_Time_SystemTimeToTzSpecificLocalTime : " & $localStr) ; Use the standard FileSetTime format : YYYYMMDDhhmmss $localStr = StringRegExpReplace($localStr,"^(....)/(..)/(..) (..):(..):(..)$","\1\2\3\4\5\6") ;MsgBox(0, "", "_Date_Time_SystemTimeToTzSpecificLocalTime : " & $localStr) Local $tLocalFileTime = _Date_Time_SystemTimeToFileTime($tLocalTime) Local $localArray = _Date_Time_FileTimeToArray($tLocalFileTime) Local $localSwitchYear = $localArray[2] $localArray[2] = $localArray[1] $localArray[1] = $localArray[0] $localArray[0] = $localSwitchYear _ArrayDelete($localArray, 7) _ArrayDelete($localArray, 6) ;_ArrayDisplay($localArray) If $format = 0 Then Return($localArray) Else Return($localStr) EndIf EndFunc ; _FileGetTimeDST()

Hi Jos You're 10x times faster than me I can't compete ; -) Well I have tried your proposal, but it does not fix my DST issue in all cases, because on one of my files, it goes to 18h, and with the other to 17h... As promised, I have developed my own code that I insert inside your above example I have followed Microsoft documentation recommendations below and it works for me 😄 My test code at this point implements only options $FT_MODIFIED (0) and $FT_STRING (1) I use for FileGetTime()... Regards #include <Date.au3> #include <Array.au3> _ArrayDisplay(_FileGetTimeDST("TEST 20190115_180000.txt", 2, 1)) _ArrayDisplay(_FileGetTimeDST("TEST 20190715_180000.txt", 2, 1)) Func _FileGetTimeDST($iFilename, $iOption = 0, $iFormat = 0) If Not FileExists($iFilename) Then Return SetError(1, 0, "File not found") If $iOption < 0 Or $iOption > 2 Then Return SetError(2, 0, "Wrong open parameter value") If $iFormat < 0 Or $iFormat > 1 Then Return SetError(3, 0, "Wrong Format parameter value") Local $hFile = _WinAPI_CreateFile($iFilename, 2) If $hFile = 0 Then _WinAPI_ShowError("ERROR: _WinAPI_CreateFile open " & $iFilename) MsgBox(0, "Error", "ERROR: _WinAPI_CreateFile open " & $iFilename) Exit EndIf Local $aTime = _Date_Time_GetFileTime($hFile) _WinAPI_CloseHandle($hFile) $aTime = $aTime[2] Local $tSystem = _Date_Time_FileTimeToSystemTime($aTime) Local $tLocal = _Date_Time_SystemTimeToTzSpecificLocalTime($tSystem) Local $LocalStr = _Date_Time_SystemTimeToDateTimeStr($tLocal,1) ; Returns yyyy/mm/dd hh:mm:ss ; Use the standard FileGetTime format : YYYYMMDDHHMMSS $LocalStr = StringRegExpReplace($LocalStr,"^(....)/(..)/(..) (..):(..):(..)$","\1\2\3\4\5\6") MsgBox(0, "", "_Date_Time_SystemTimeToTzSpecificLocalTime : " & $LocalStr) Return $LocalStr EndFunc ;==>_FileGetTimeDST

I have begun to code something, but will try that also as soon as possible next WE or after ☺️

☺️

Too funny Interesting for me I like old school terms, that's true Really, I'm a little old school, exact And, i am funny, well I hope so, at least, I try to be funny Regards

You're not the forum master for nothing 😀 ! Difficult to say something else than well noted and I shall try !! I appreciate your answer to position myself for the next steps... Anyway, I need to finalize my own function to achieve the result 😉 Regards (Sorry for the English = I'm just a froggy French...)

No votes or remarks for an adjusted FileGetTimeDST() to fix the W10 new display method ?

Yes, aliens are laughing FileGetTimeDST() could stop the sniggering...

Hi Mbee I see you have posted many things around Dbug in the past I'm late, but I hope ut could be useful I use _Dbug.au3 from valdemar1977 : Old, but nice ! Just use that code fragment : ; Debug #include "..\..\Dbug\_Dbug.au3" ; À commenter si usage de _Dbug.au3... ;#AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 ../.. is my own path config... Use F5 for debug and comment it to build a usable .EXE 😉 Regards

Hi Jos After all the previous discussions, we must forget my sample 20190115_180000_test.jpg : just a sample and not an essay on picture geo-localization It's not a question for photos, but for all files on my Windows ! If I want to set 2021 15 01 18:00 to my files with FileSetTime(), it will put 19:00 visible in the file properties with Windows : that's the real bad trick here... Ask me if all my peregrinations are unclear 🤔 Regards

Yes Right But I didn't mean to correct all date/time possible issues, even for distant travelers I said, as far are today's software is concerned with the existing API : that means TZ in Windows for the current user in its country zone Unless Windows is able to get EXIF geo-info from pictures to choose the traveled TZ in the API : not possible just now That way, even in our own local time zone, the FileGetTime does not display a time in coherency with what is displayed locally in Windows As a user in my own country, even my local time is not correct with FileGetTime... Regards PS : That's a very strong argument for those who advocate dropping TZ and DST to use UTC only everywhere = That's true, but it is not used/displayed that way in smartphones and Windows = For a future implementation 😏 by Microsoft & all...

Hi Jchd I like science and I just can say how right you are ; the time is very subtle and even the time essence itself is not really known in physics As far are today's software is concerned with the existing API, it is yet possible to give simple and easy ways to manage time in 99.9% of cases What is disconcerting for a not-expert user is to take the date/time of 20190115_180000_test.jpg ; to put it in FileSetTime() that is the principal function provided in AutoIt, and to see 19:00 inside Windows in the file properties !? In my case, this is 50% of errors to change date/time of files in the year for the user... This is also not consistent now with the Windows user's experience... I'm not a Windows developer, so I didn't know for example that AutoIt was giving an exact mapping of all internal Windows functions in its CORE Library For example, with FileFindFirstFile and FileGetTime that are found in the Win32 API And it's very interesting to go to the Windows detailed explanations when needed I will have discovered the DST mess with : https://docs.microsoft.com/en-us/windows/win32/sysinfo/file-times Thus, just a short note in this case in the FileGetTime AutoIt Help with a link to Win32 API File Times about DST would have been very helpful The AutoIt Function Reference could also refer to Win32 API with a link to propose additional information for those who could need it Furthermore that AutoIt is already a very very well documented dev tool 😊 I know now how to bypass with complex functions the "not-really-bug" I encountered with FileGetTime(), but the top of the top will be a function added to the CORE Library named FileGetTimeDST() or FileGetTime2() to propose the adjusted DST fix in a very simple way 😄 What do you think ? Regards

Hi Jos — Jchd — Melba23 I did not imagine that so many answers will come so quickly with so much insight : incredible ! 1/ The fact is that before W7 with WinXP and older OS, the DST date/time was in accordance to the Windows properties displayed, as said in comments above With W7 to W10, there is a change that corrects the properties displayed by Windows to be in coherency with the date of the filename, but yet not true for the old DOS DIR command... (I don't know for PowerShell...) Thus, Windows 10 displays 18:00 for a JPG tagged 1800 = Good from the user point of view now ! 2/ Yes, it's exactly the subject 😉 This was, let's say, OK in the past with old DOS/Windows settings, but NOK with regards to Windows new behavior So, Jos, you're definitely right in your explanations The fact is at time of the 20190115_180000_test.jpg picture, the time was really 18:00, and now, Windows displays 18:00, but FileGetTime shows 19:00 using current DST Not understandable from the user's point of view since W7... 3/ But, as said above in the link proposed : https://docs.microsoft.com/en-us/windows/win32/sysinfo/file-times I understand this is certainly a pure Windows mismatch ! These AutoIt functions only reflect Windows functions : these are not original written AutoIt libraries, but a useful mapping to Windows API (?). If FileGetTime is a pure mapping of Win32 DLL functions and shall be kept as this, Jos, I understand your proposition is becoming even the rule... 😏 4/ Question : Jos, does FileGetTime is a pure Windows library mapping in AutoIt or is that adjustable ? 5/ Question : Without even discussing code correction, would it be possible, at least, to add a remark in the AutoIt Help AutoIt.chm ? This will help AutoIt users not to wrongly manipulates dates with FileSetTime()... I would have been happy last week to read these forum explanations in the documentation of AutoIt take care of DST... Regards

Hi FileGetTime() uses an improper TZ+DST shift at today's date ... ... and not a TZ+DST shift at the date of the file itself ! Thus, +/-1h error on the time... Here a sample : Filename : 20190115_180000_test.jpg FileGetTime : 20190115190000 And the display file properties inside Windows 10 shows the correct 18:00 for Date Modified and not the AutoIt erroneous 19:00... 🙄 That causes errors when setting faraway date/time with a string to a file with FileSetTime ! Regards