But on any modern CPU, clock speed won't be constant. It's not compile time constant, nor a runtime constant. Its variable over time. You'd have to record the clock speed over time and the ticks, so why not just record actual time?
The CPU clock varies, but all modern CPUs have some counter that is incremented at a constant frequency, like the Time Stamp Counter (TSC) on Intel/AMD CPUs.
When discussing hardware clock ticks used for time measurement, the ticks from TSC or similar counters are meant and not ticks from some counter that counts cycles of the CPU clock, like provided by the performance counters.
The variable CPU clock frequency can be measured by computing the ratio between the ticks accumulated by the corresponding performance counter and the ticks accumulated by the TSC (or similar counter), for which the clock frequency is constant and known.
The post, at least, seems to have no word about a web interface, though? I'm aware of a number of CalDAV/CardDAV servers, but they all seem to be designed for a workflow where you only access the calendar from a mobile app. Conversely, standalone web calendars like the fullcalendar.io thing linked in a sibling post make no mention of any support for CalDAV or other ways to synchronise with phones and calendar apps.
It's the integration of both that makes Google (and, I guess, Nextcloud) useful: you can add an event on your computer (which is where most of the scheduling and planning happens), and then inspect and be alerted of it on your phone (which is with you when you are in a random location and need to be reminded of an event).
Even if there does exist a standalone JS calendar application that can sync with CalDAV, you would be left with an awkward setup when self-hosting, since now for no obvious reason you need to have two services on the same machine (the database and the frontend) that maintain a copy of the same state and need to sync with each other constantly.
reply