The Factory Timezone
data.iana.org
data.iana.org
> 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.
* https://github.com/django/django/blob/main/django/conf/globa...
...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.
Electronics these days measure time passing by counting oscillations of e.g. a quartz crystal. They know e.g. 16000000 oscillations is 1 second +- 0.001%. They don't know when 4pm is.
...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).
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.)