> 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.
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.
settings.py is automatically generated when creating a new project and overrides this global default. If you create a new django project and run it, it uses UTC.
A clock can exist in more states than just "UTC with unconfigured local offset" and "maybe-local-maybe UTC, but at least it's configured!" - what about "Dallas RTC battery died, lol" or "we honestly have no idea because we use GPS for UTC, but China/Russia/etc are conducting GPS spoofing"?
...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].
> dumb-question: why couldn't VCRs get the time from the TV signal?
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?
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.
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.
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.