Kaspar Schleiser

> A common format for accurate time synchronization across the network is a 64 bit timestamp where the upper 48 bits count the seconds since the Unix epoch and the...

> I'm not sure what kind of overhead / conversion losses would be involved by using ztimer, but if it can make use of real timer ticks (instead of ms)...

1. I like the way time is represented as "seconds" and "us", with "us" seamlessly only showing the accuracy that the rtt provides. 2. This quite a bit simpler than...

> That's already the case with existing users of RTT/RTC. `ztimer_msec` is incompatible with Deep Sleep operation in it's current form. this I don't understand. `ztimer_msec`, when configured to use...

> The issue with `ztimer_msec` is that we lack an API that lets us expose multiple low-power timers, there can only be a single RTT and a single type of...

> Yes or rather it becomes inherently racy to use the RTT alarm to wake from Deep Sleep as some random driver might set it's own RTT alarm inbetween. you...

I think I'm realizing what you're trying to accomplish. You'd like to be able to set "wake me up in N days" and deep sleep in the meantime. ztimer is...

Why didn't you say so ... :) How about this: 1. with https://github.com/RIOT-OS/RIOT/pull/18122, ztimer64 can make use of an epoch. 2. we add an API do expose forced deep sleep....

Hm, it would be API breaking **edit** to remove, but, is there a use case for keeping the port as string?

> Indeed, but given that Zephyr did not put it in its own repository, that seems indeed to be overkill... How long does the fetch take with `--depth=1` roughly? Maybe...