Re: [TCLCORE] TIP 723: monotomic clock for after, independent of TIP 233 (Tcl_SetTimeProc/Tcl_QueryTimeProc), MS-Windows only

[Dipl. I. S. G. B. <se...@us...>]

 

I don't understand the issue with manual adjustment of clock. 
Even if it is done fully manually (without the NTP), the clock (UTC)
shall be consistent, because otherwise you'd immediately observe 1 hour
difference even in TZ CET (see my examples with 1743296399). So the
adjustment of system time ±1 hour shall happen in current TZ (CET/CEST),
what shall reflect to few seconds maximally in the UTC time (what
doesn't jumps normally). The same is basically valid for clock
milliseconds or clock microseconds.
Just I didn't inspect yet how windows part of tcl would consider it,
because it happens in calibration thread there (only windows thing, *nix
doesn't have it), which I completely removed in my RFE, due to similar
issues (but short jumps), since the calibration was affected by timing
issue and by jumps it would near the real time of system slow and can
deviate few seconds long unless gets fully synchronous. This was the
main reason why I removed the calibration thread in my RFE and rewrote
the calibration with different algorithm, that can drift more accurately
(only in single direction).
Maybe this is the issue you had? But it shall be definitely not ±1 hour
jumps (in UTC time), but small jumps. 

Hope this helps,
Sergey. 

23.05.2025 08:27, Harald Oehlmann wrote: 

> ...
> 
> About the "summer time change". The concerned systems run without NTP and the change is done manually. So, the clock is manually turned back by one hour once per year.
> This may be detailed in the tip.
> 
> Thanks for all,
> Harald
> 
> Am 22.05.2025 um 17:38 schrieb Dipl. Ing. Sergey G. Brester:
> I don't know why it shall be limited to Windows only, because all 3 points are affecting *nix in the same way: * manual time adjustment (is possible with `date -s`) * suspension of the system (suspend of VM, hibernation, etc) * automatic time adjustment (via ntpd and co) Also there is a mistake in the TIP - "specially on day time switching +/- 1 hour". Because DST-switches normally doesn't adjust the clock in UTC (GMT), which is running continuously. Everything what asking [clock seconds], [clock milliseconds], [clock microseconds] (or related C-API functions) etc is not affected by DST-switches at all. The DST-switch happens only in related timezone (table of offsets stored in tzdata) and doesn't exist without TZ context (pure UTC time). Just for illustration: # forward DST jump in CET-TZ: % clock format [expr {1743296399 + 0}] -timezone :Europe/Berlin Sun Mar 30 01:59:59 CET 2025 % clock format [expr {1743296399 + 1}] -timezone :Europe/Berlin Sun Mar 30 03:00:00 CEST 2025 #
backward DST jump in CET-TZ: % clock format [expr {1761440399 + 0}] -timezone :Europe/Berlin Sun Oct 26 02:59:59 CEST 2025 % clock format [expr {1761440399 + 1}] -timezone :Europe/Berlin Sun Oct 26 02:00:00 CET 2025 The issues are only manual or automatic time adjustments affecting UTC- time, and suspension/hibernation. However as already said it definitely affecting all systems that using wall clock (and need a switch to monotonic time). Regards, Sergey. 21.05.2025 12:35, Harald Oehlmann wrote: Dear TCL team, please allow me to propose a TIP to cure one of my biggest issues on TCL and MS-Windows: after does not fire if the wall clock changes. The TIP text is here: https://core.tcl-lang.org/tips/doc/trunk/tip/723.md [1] <https://core.tcl-lang.org/tips/doc/trunk/tip/723.md [1]> I am sorry to write it, as it is written (e.g. no respect on TIP233, Windows only). But those are the conclusions taken on recent discussions on the forelast biweekly telco and on the related bug tickets and on
the core list. I hope we will find a better solution, but this is my "minimum viable outcome" to this very urgent and annoying issue. Thanks for all and take care, Harald
 

Links:
------
[1] https://core.tcl-lang.org/tips/doc/trunk/tip/723.md