Trong Posted August 3 Posted August 3 I have a problem when getting the time to process (with @HOUR @MIN @SEC macros) when changing the time zone, the system time also changes but the macro time is not updated according to the system time. Is this a serious bug of autoit? Regards,
argumentum Posted August 3 Posted August 3 (edited) just curious. Does _NowCalc() behave as it should compared to the @macros ? Edit: Yes, only the macros are wrong. Spoiler expandcollapse popup#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Version=Beta #AutoIt3Wrapper_UseX64=y #AutoIt3Wrapper_Change2CUI=y #AutoIt3Wrapper_Res_SaveSource=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <Date.au3> HotKeySet("{ESC}", "Terminate") Func Terminate() Exit EndFunc ;==>Terminate Global $idEdit Exit test() Func test() ; change TimeZones while running this script GUICreate(StringTrimRight(@ScriptName, 4) & ' - ' & @AutoItVersion & ' (' & (@AutoItX64 ? 'x64)' : 'x86)'), 600, 400) $idEdit = GUICtrlCreateEdit("", 0, 0, 600, 400) GUISetState() GUICtrlSetData($idEdit, "Press ESC to exit" & @CRLF & @CRLF, 1) ConsoleWriteIt() AdlibRegister(ConsoleWriteIt, 5000) ; ConsoleWriteIt every 5 sec. Do Until GUIGetMsg() = -3 EndFunc ;==>test Func ConsoleWriteIt() Local $sOut = (_NowCalc() = _NowCalc_viaMacros() ? '-' : '! !!!') & ' NowCalc: ' & _NowCalc() & _ @TAB & TimeZone() & @TAB & 'viaMacros: ' & _NowCalc_viaMacros() & @CRLF ConsoleWrite($sOut) GUICtrlSetData($idEdit, $sOut, 1) EndFunc ;==>ConsoleWriteIt Func _NowCalc_viaMacros() Return @YEAR & '/' & @MON & '/' & @MDAY & ' ' & @HOUR & ':' & @MIN & ':' & @SEC EndFunc ;==>_NowCalc_viaMacros Func TimeZone() Local $aInfo = _Date_Time_GetTimeZoneInformation() If @error Then Dim $aInfo[8] = [-2] ShowTimeZoneInformation($aInfo, "") Return StringRight(' ' & $aInfo[1] & '(' & $aInfo[7] & ')', 11) EndFunc ;==>TimeZone ; Show time zone information Func ShowTimeZoneInformation(ByRef $aInfo, $sComment) ConsoleWrite(@CRLF & "+ ******************* " & $sComment & " *******************" & @CRLF) Local $aDaylightSavingsSetting[5] = ["Error", "Failure", "not used in the current time zone", _ "operating with standard time", "operating with daylight savings time"] ConsoleWrite("+ Result ............: " & $aInfo[0] & ' = ' & $aDaylightSavingsSetting[$aInfo[0] + 2] & @CRLF) ConsoleWrite("+ Current bias ......: " & $aInfo[1] & @CRLF) ConsoleWrite("+ Standard name .....: " & $aInfo[2] & @CRLF) ConsoleWrite("+ Standard date/time : " & _Date_Time_SystemTimeToDateTimeStr($aInfo[3]) & @CRLF) ConsoleWrite("+ Standard bias......: " & $aInfo[4] & @CRLF) ConsoleWrite("+ Daylight name .....: " & $aInfo[5] & @CRLF) ConsoleWrite("+ Daylight date/time : " & _Date_Time_SystemTimeToDateTimeStr($aInfo[6]) & @CRLF) ConsoleWrite("+ Daylight bias......: " & $aInfo[7] & @CRLF) EndFunc ;==>ShowTimeZoneInformation Edited August 4 by argumentum better Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 3 Posted August 3 1 hour ago, Trong said: Is this a serious bug of autoit? I opened a trac ticket to fix it. Trong 1 Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 4 Posted August 4 #include <WinApi.au3> GUIRegisterMsg($WM_TIMECHANGE, _WM_TIMECHANGE) Func _WM_TIMECHANGE($hWnd, $iMsg, $wParam, $lParam) #forceref $hWnd, $iMsg, $wParam, $lParam ConsoleWrite('> >>> WM_TIMECHANGE' & @CRLF) EndFunc @Trong, the above triggers when the time zone changes. Maybe you can reload if the unlikely possibility that it ( the time zone ) changes, for now, until the next version is released. Trong 1 Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
Trong Posted August 5 Author Posted August 5 5 hours ago, argumentum said: #include <WinApi.au3> GUIRegisterMsg($WM_TIMECHANGE, _WM_TIMECHANGE) Func _WM_TIMECHANGE($hWnd, $iMsg, $wParam, $lParam) #forceref $hWnd, $iMsg, $wParam, $lParam ConsoleWrite('> >>> WM_TIMECHANGE' & @CRLF) EndFunc @Trong, the above triggers when the time zone changes. Maybe you can reload if the unlikely possibility that it ( the time zone ) changes, for now, until the next version is released. Will the normal program check the time zone regularly? Anyway I will add and run this code in the time function! Thank you. Regards,
argumentum Posted August 5 Posted August 5 Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 5 Posted August 5 6 hours ago, Trong said: Will the normal program check the time zone regularly? I don't have access to the source for AutoIt3 but: I imagine that asking the time via a DllCall is quite slow and unnecessary to populate the time macros. All the code have to do is keep a tick counter or ask kernel ( no clue ), and adjust time based on setting on start of the program. The oversight is in not trapping/getting the WM_TIMECHANGE event to recalculate the tick to time correlation. So to me this is an oversight rather than a bug in my trend of thought. In future versions the AutoIt3 executable should be aware ( if the code is there ) to adjust for when the time changed either because of the time zone changed or local time sync, or any reason the "tick to time" changed. All this I explain is based on my imagination. Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 5 Posted August 5 (edited) 7 hours ago, Trong said: I will add and run this code in the time function! On that regard, using the Date.au3 include functions will give you the correct timings because in the last update (v3.3.16.1) the UDF got updated to use only DLL calls and therefore the time is the correct time, all the time, down to the @MSEC. Spoiler ConsoleWrite(@CRLF & _NowCalc_MSec() & @CRLF & @CRLF) Func _NowCalc_MSec() Local $tLocalTime = _Date_Time_GetLocalTime() If @error Then Return SetError(@error, @extended, "") Return $tLocalTime.Year & "/" & StringRight('00' & $tLocalTime.Month, 2) & "/" & StringRight('00' & $tLocalTime.Day, 2) & " " & _ StringRight('00' & $tLocalTime.Hour, 2) & ":" & StringRight('00' & $tLocalTime.Minute, 2) & ":" & StringRight('00' & $tLocalTime.Second, 2) & _ "." & StringRight('000' & $tLocalTime.MSeconds, 3) EndFunc ;==>_NowCalc_MSec ...added the MSec example to explain why down to the millisecond So unless your code uses @SEC to wait X sec or @MIN to wait X min, the Date.au3 functions can replace all your other needs, without having to reload the script because the time in the PC changed somehow. <thinking> Edit: ...thinking about it, now the issue is: did this sec. or min. or hour skipped ? Then we'll need some thing like Local $hTimer = TimerInit() TimerDiff($hTimer) >= 1000 ; 1 sec because otherwise the unexpected event will mess up the code based on that time is a steady count forward, when only the tick is, as time is a human representation of time as per locality. Therefore we should use UTC time all the time, as time zone. Then there is time sync. Or do something else like, woodworking. Then again, there is the humidity, grain direction, ...isn't there anything easy anymore 🤪 So we are asking to fix it, to create a problem, because most of us are "scripters" and don't take these things into consideration as experienced programmers do 🤔 I guess the tick is all we can trust. </thinking> Edited August 5 by argumentum thinking out loud Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 5 Posted August 5 (edited) ...my head is a chatter box. Talking with the @Trong in my head, I was explaining the time it would take to execute this or that, and the options.... but then am like, I should try it out, measure it. And: Spoiler #include <Date.au3> Local $hTimer = TimerInit() ConsoleWrite('- ' & TimerDiff($hTimer) & ' mSec to execute nothing, as a baseline for this ConsoleWrite()' & @CRLF) $hTimer = TimerInit() ConsoleWrite('- ' & _NowCalc_MSec() & @TAB & TimerDiff($hTimer) & ' mSec to execute via UDF' & @CRLF) $hTimer = TimerInit() ConsoleWrite('- ' & _NowCalc_viaMacros_MSec() & @TAB & TimerDiff($hTimer) & ' mSec to execute via macro' & @CRLF) $hTimer = TimerInit() ConsoleWrite('- ' & sec() & @TAB & TimerDiff($hTimer) & ' mSec to execute @SEC macro replacement' & @CRLF) $hTimer = TimerInit() ConsoleWrite('- ' & @SEC & @TAB & TimerDiff($hTimer) & @TAB & TimerDiff($hTimer) & ' mSec to execute macro' & @CRLF) Func _NowCalc_MSec() Local $tLocalTime = _Date_Time_GetLocalTime() If @error Then Return SetError(@error, @extended, "") Return $tLocalTime.Year & "/" & StringRight('00' & $tLocalTime.Month, 2) & "/" & StringRight('00' & $tLocalTime.Day, 2) & " " & _ StringRight('00' & $tLocalTime.Hour, 2) & ":" & StringRight('00' & $tLocalTime.Minute, 2) & ":" & StringRight('00' & $tLocalTime.Second, 2) & _ "." & StringRight('000' & $tLocalTime.MSeconds, 3) EndFunc ;==>_NowCalc_MSec Func sec() ; @SEC macro replacement Local $tLocalTime = _Date_Time_GetLocalTime() If @error Then Return SetError(@error, @extended, "") Return StringRight('00' & $tLocalTime.Second, 2) EndFunc ;==>sec Func _NowCalc_viaMacros_MSec() Return @YEAR & '/' & @MON & '/' & @MDAY & ' ' & @HOUR & ':' & @MIN & ':' & @SEC & '.' & @MSEC EndFunc ;==>_NowCalc_viaMacros_MSec - 0.0012 mSec to execute nothing, as a baseline for this ConsoleWrite() - 2025/08/05 07:07:44.692 0.0592 mSec to execute via UDF - 2025/08/05 07:07:44.692 0.2438 mSec to execute via macro - 44 0.0361 mSec to execute @SEC macro replacement - 44 0.0025 mSec to execute macro is faster to use the UDF for a full timestamp, but not for a single macro. Edited August 5 by argumentum Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
argumentum Posted August 6 Posted August 6 Ok !. The the trac entry is marked as fixed Trong 1 Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now