> It is intended for use as a factory default, to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC.
Does this mean:
1. a system which believes it has an accurate idea what the current UTC time is, but doesn't know where it is on Earth (or where its operator conceptually wants it to pretend it is)?
2. Or a system which has had its clock set manually, but its TZ has never been set (therefore it has no idea what the UTC time is, and therefore cannot reliably generate or store a valid time with offset.
3. Or a system which knows both its clock and its TZ have never been set?
For the first one, it seems silly, since as long as you're recording correct timestamps, fixing the display timezone later is easy and nondestructive. For 2 it seems like the OS should require setting TZ to set a time. For 3, I suppose this is actually mildly useful, since it's easy for an OS to detect if you have inited the RTC from its original starting point, and specially flagging datetimes stored while it's in that state could help to clean them up later when the correct time is known.
...the way I see it, 1980s VCRs got it right the first time with "+00:00" on a flashing VFD display, taunting you to re-set it again - all because someone unplugged it by mistake (dumb-question: why couldn't VCRs get the time from the TV signal?).
(What I mean, is that I think all systems (hardware and software) around the world just should standardize on flashing a message simply reading "+00:00" for all unintentional clock states. Clocks are one thing that I feel should not feature graceful-degradation - consider that's the whole origin of the idiom that "a stopped clock is still correct twice a day"; I'd very much rather a stopped-clock's hands broke-off entirely instead of risking it being misinterpreted by people who think the clock works just fine but they themselves have a bad case of saccade chronostasis[1].
Later VCRs have that feature...
Huh, but a computer without time would be confusing indeed. A process would ask the OS, "What time is it?", "0:00", it can't even sleep for 5 seconds because the hardware clock will never tell the OS "it's 0:00:05 now" -- if the OS counts itself (doing something rudimentary like, "well it's a 1 GHz CPU, let's increment the counter every billion cycles"), then it's implemented a clock!
…huh, turns out some US-market VCRs would automatically tune to PBS specifically for a special time-signal embedded within the TV signal, and apparently not all PBS stations participated so it would never work for some people.
I’m guessing it was something encoded into the VBI like Closed Captions and Teletext, etc? I couldn’t find the name for such a time system let alone a spec. Can you tell me where to look?
https://www.researchgate.net/figure/The-XDS-Line-21-Time-Cod...
I’m not a philosopher; but on a technical basis, lots of OS work just fine on embedded systems that don’t provide a real-time time-of-day clock and only have time-since-booted to work on - but I don’t believe either are strictly necessary for a preemptive OS to work just fine provided the CPU itself supports millisecond-scale interrupts for the thread scheduler to work. But that made me wonder if it matters at all that a process’ time quanta have a wall-clock-based unit of quanta (e.g. people say Windows uses a 16ms quanta for foreground processes and something else (possibly variable?) for background processes. I imagine a scheduler could use a simple cpu clock cycle counter instead. Even though clock cycles themselves are also variable. And if it’s variable then it cannot be used as a clock.
…so who needs a clock? Turns out you don’t need one. I suppose that means we should just live in the present. Take each day… hour… second as it comes.
…or something. I dunno. As I said, I’m not a philosopher.
* https://github.com/django/django/blob/main/django/conf/globa...
...everything should be based on UTC though!
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".
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.).
And IIRC all iphones had a first test GPS fix from somewhere in the mid US. We speculated that it was part of a factory quality check or something.
Reminds me of an anecdote that getting a rideshare in Moscow is difficult nowadays, because GPS for the whole city is jammed and the driver won't be able to find you.
The major ones are GPS, Galileo, Glonass, Baidou.
Currently, no country uses that. And it has the nice property of making time go forward when it’s configured.
(Which was way more boring than most people might expect, unless you were a GM and could see the hundreds of GM WoW avatars standing at precisely the same coordinates.)