CLOCK_TAI or CLOCK_REALTIME instead of CLOCK_MONITONIC/CLOCK_BOOT?

[spacelama]

Per (closed) #1019, why are we giving the user or their scripts some arbitrary value for TIMESTAMP, rather than a value that can be directly piped into libraries that can make use of seconds since the epoch?

So the question becomes: why is dunst using CLOCK_MONOTONIC at all? There's plenty of use-cases for specialised precision interval timekeeping, but is showing notifications one of them? Oh no, a leapsecond has happened once every 5 years. Do I really care that my notification came in 65 seconds ago and not 64 seconds ago? You could get away fine with using CLOCK_REALTIME, but heck, if you really care about monotonicity, just use CLOCK_TAI -- it's currently ~38 seconds out from the unix epoch. But at least then $DUNST_TIMESTAMP and dunstctl history | grep -A3 timestamp bear some resemblance to something useful.

[fedang]

I guess that's an historical legacy. Ideally the timestamp would be milliseconds since epoch

[fedang]

Backward compatibility and portability permitting, this could reasonably be reworked

[Nickwiz]

If I am to speculate on rationale; the use of CLOCK_MONOTONIC (POSIX) has been chosen to assure time records are consistent "no matter what" and never negative clock jumps.

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/time.h.html

There is more then leap-seconds that can affect real time and CLOCK_TAI (Linux-specific). E.g. sysadmin adjusting time, system-time being wrong and updated by NTP when you go online or what ever, clock drift etc.

Without knowing the code base; this in turn can perhaps affect queues, waits, etc?

---

• CLOCK_MONOTONIC (POSIX) is not affected by manual time changes etc. It also does not count when system is suspended.
• CLOCK_BOOTTIME (Linux-specific) on the other hand counts time the system is suspended and hence the "solution" in linked ticket will fail as that calculates diff between boot-time and dunst-timestamp not monotonic and dunst. https://man7.org/linux/man-pages/man2/clock_getres.2.html

As /proc/uptime includes time spent in suspend https://www.man7.org/linux/man-pages/man5/proc_uptime.5.html the script in linked ticket will fail if system has been suspended. (I assumed dunst used boot-time/uptime back then).

If it is MONOTONIC we get; as an example:

Say:

DT = DUNST_TIME  (MONOTONIC)
BT = BOOT_TIME   (aka uptime)
RT = REAL_TIME   (wall clock)

System is booted, one send a message, system is suspended, awakened, new message sent. Now times per script are off.

   RT           |   DT |   BT
----------------+------+------------------
12:00           | 0:00 | 0:00 <- boot up
12:55 MSG#1:    | 0:55 | 0:55 <- dunstify msg 1
13:00 history#1 |      | 1:00 <- request history
14:00 Zzz       | 2:00 | 2:00 <- suspend
15:00 Wakeup    | 2:00 | 3:00 <- wake up, 1h skew monotonic v. boottime
15:30 MSG#2:    | 2:15 | 3:15 <- dunstify msg 2
15:45 history#2 |      | 3:45 <- request history
----------------+------+------------------

Results of history requests:

DUNST_2_REALTIME = REALTIME - BOOT_TIME + DUNSTTIME

          RT     BT     DT    Result
history#1:
MSG#1: 13:00 - 1:00 + 0:55 => 12:55 <- OK

history#2:
MSG#1: 15:45 - 3:45 + 0:55 => 11:55 <- OK
MSG#2: 15:45 - 3:45 + 2:15 => 14:15 <- 1h skew

One possible solution could be using time_namespaces https://man7.org/linux/man-pages/man7/time_namespaces.7.html, which has offsets for monotonic and boottime.

---

Anyhow; that is purely for a fix for as-is per date, and assuming it is actually CLOCK_MONOTONIC in use, and only for Linux.

[fedang]

I am considering switching to CLOCK_REALTIME. Hopefully nothing will break if we change that

[fedang]

@spacelama @Nickwiz please take a look at #1535. This is just a sketch, a more solid solution is needed eventually. I was thinking of exposing to dunst history both a monotonic and unix timestamps. we need the monotonic time for queues and expiration, but exposing a unix epoch is cheap enough to warrant this QoL improvement

[spacelama]

@fedang, taking a very quick look at the code, I guess it's expected that ./dunstctl history would not return the new real_timestamp - is that correct, or did I miscompile?

[fedang]

@fedang, taking a very quick look at the code, I guess it's expected that ./dunstctl history would not return the new real_timestamp - is that correct, or did I miscompile?

It should return real timestamp

                g_variant_builder_add(&n_builder, "{sv}", "timestamp", g_variant_new_int64(n->real_timestamp));

[Nickwiz]

@spacelama @Nickwiz please take a look at #1535. This is just a sketch, a more solid solution is needed eventually. I was thinking of exposing to dunst history both a monotonic and unix timestamps. we need the monotonic time for queues and expiration, but exposing a unix epoch is cheap enough to warrant this QoL improvement

Sorry for late reply. I am in the midst of IRL things that take precedence but can take a look at it whence things hopefully settles. Read as: not now, hopefully later. I also spotted some erroneous things in the example of my previous post – albeit the essence of it should be ok.