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.
Something which bugs me about UNIX time is that, contradictory to its colloquial name (epoch time), UNIX time does not increase linearly and does funny stuff on leap seconds.
Even CLOCK_MONOTONIC doesn’t increase linearly, it is affected by NTP updates.
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.
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.
UNIX time is _an_ example of a type of epoch time, with extra rules and conditions.
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.).
There’s an argument to say that the datetimes should be stored in UTC. But if a user wants to see datetimes in their local time zone (a config or w/e), then you gotta hold onto a time zone!
Not really defending the Factory timezone but I do think we gotta think about timezones
A subscription will renew at 2025-08-16 04:04Z, and the billing system must send an email to the user reminding them of this. What date do you show in the email?
A meeting happens every Tuesday at 9am, starting February 18, 2025. What time does the calendar show once DST kicks in?
Systems can always translate UTC to a user’s own time-zone for display purposes, including accommodating DST; but internally all values are stored as UTC and all calculations are performed on UTC values.
Yes, but that’s handled by the user’s software when they access or edit the appointment. All calendaring software I know uses UTC internally like that, where the tz adjustments (including daylight savings rules - and historical too! are the responsibility of the topmost, user-facing parts of the system. I don’t know why I’m getting downvoted for saying this - am I missing something?
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.