You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as i3status, if used with a tztime shows that module's clocktime on each refresh, the clock naturally lags behind realtime. If you for example use an interval of 60s, your clock if showing minutes can be up to 59s off.
To resolve this, one could introduce an optional setting to the tzdata module, either a correction value for the time directly or a boolean, leading to the time being corrected by the globally specified refresh interval.
If set, instead of lagging behind, the clock would run ahead of real time (and therefore never be late), which I personally find preferrable.
Would a PR implementing this have a chance of being merged?
The text was updated successfully, but these errors were encountered:
Hi,
as i3status, if used with a
tztime
shows that module's clocktime on each refresh, the clock naturally lags behind realtime. If you for example use an interval of 60s, your clock if showing minutes can be up to 59s off.To resolve this, one could introduce an optional setting to the tzdata module, either a correction value for the time directly or a boolean, leading to the time being corrected by the globally specified refresh interval.
If set, instead of lagging behind, the clock would run ahead of real time (and therefore never be late), which I personally find preferrable.
Would a PR implementing this have a chance of being merged?
The text was updated successfully, but these errors were encountered: