> to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC
...everything should be based on UTC though!
...everything should be based on UTC though!
Real time scientific, physics, and engineering data acquisition and processing applications? Goodness no.
Certainly nothing that might want to generate a waypoint heading update via a division of elapsed time. Not with those random UTC leap seconds that can go either way (although, until now, they've all fallen in one direction).
There's a reason serious real time real world data processing goes with epoch based time, lapsed time since <mark>, it has the nice feature of being monotonically increasing.
Apparently newer Linux kernels support CLOCK_MONOTONIC_RAW which is not affected by NTP, but even that may not increase linearly: it’s not updated when the system is in standby.
Then there is also CLOCK_BOOTTIME which is monotonic and accounts for time spent in standby.
Neither of these seem to be POSIX standardised, though.
https://linux.die.net/man/2/clock_gettime
This clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremental adjustments performed by adjtime(3) and NTP.
If the adjustment in delta is positive, then the system clock is speeded up by some small percentage (i.e., by adding a small amount of time to the clock value in each second) until the adjustment has been completed. If the adjustment in delta is negative, then the clock is slowed down in a similar fashion.Not all epoch time counters are UNIX time though.
The usual case, when referring to an epoch time counter being used, is a uniform, increasing count of elapsed time in a standard fixed length unit (seconds, cycles, orbits, etc.).
Not really defending the Factory timezone but I do think we gotta think about timezones
A meeting happens every Tuesday at 9am, starting February 18, 2025. What time does the calendar show once DST kicks in?
More sophisticated calendar software will take into account holidays or use offsets from month start/end. i.e. "we'll have a meeting at 9:00pm Tokyo time, every last business day of each month".
> You can't just store UTC and be done with it
Right; though there are different approaches to handling this in software; one approach is to create concrete (as opposed to virtual) records for each occurrence of the recurring pattern[1] so that any other software concerned with viewing/handling those events can be given precomputed UTC values and not have to worry about local user settings or parsing recurrence patterns.
...whereas another approach, which you mentioned, is to treat those occurrences as virtual-events derived from the (local-to-the-user) recurrence pattern, which requires the software to retain full timezone info (not just UTC offset) for the pattern, which increases software complexity (not to put it down; I'm simply saying that each approach has its benefits and drawbacks).
[1] For practical reasons, systems like these only generate concrete records for, say, 1-2 years out into the future (and retain the ability to mass-update their individual occurrence times when the user's pattern specification changes).
So what you say is true - and demonstrates that my desire for UTC-only systems is unworkable... but only for this particular scenario.
Fun-fact: I have a legit copy the four specs in ISO 8601 ($500, ouch!) , and buried in ISO 8601-2:2019 section 7.3.1 there's an admission of inadequacy:
> Representations of local time of day as defined below make no provisions to prevent ambiguities in expressions that result from discontinuities in the local time scale (e.g. daylight-saving time)
...whereas if everyone used UTC everywhere all-the-time for everything (i.e. ban daylight savings time!) then this problem wouldn't exist and my original point that started this whole thread remains true :3
This approach assumes that concrete records can actually be computed by the time the series is created. That may not be feasible. Some countries pass their DST policy on very short notice (i.e., days or months rather than years).