> 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.
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?
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.
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.
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?
If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. Further, what is displayed depends on the viewer's location (because daylight savings times change differently based on location/date). IOW, the time of the meeting occurs on TWO UTC times, not one. You can't just store UTC and be done with it. You need the originating timezone too. In other cases you may need the date the item was created as well.
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.
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.).
Trivia: a long time ago when an sqlite file was found on the iphone that has a full location history, some random HNer connected with me to make a web app that let the user see their location history if they uploaded their file.
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.
That's turning locations into coordinates (ip geolocation). It's to be expected that the gps log only bases their logs on the coordinates from the GPS from the phone.
It'd be more practical to have a faraday cage and several GPS transmitters to spoof a location (let's say 33.783, -118.14899); turn on the device, if it tells you it's located at 33.783, -118.14899, then it's GPS receiver is working correctly, anywhere else, then there's something wrong...
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.
Is it easier to spoof GPS transmissions such that the phone will calculate it's at a specific coordinate? Rather than just check where they are reporting?
If they're worried about someone guiding missiles with satnav, they are probably jamming those both plus the European one, would be my guess, or since they control their own GLONASS system they could be encrypting it if it supports that, or shutting it down in those areas.
Another fun "timezone" is the "Anywhere on Earth" designation referring to when a time has passed everywhere on Earth. It does not seem to be referenced in the IANA database though :)
And I thought this was a timezone to be used exclusively in factories - something like “always use utc on a server”, I thought this was meant to be used in factories!
(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.)
Explanation from https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/EX...
> 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.
> unconfigured system
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.
So its a valid time zone used to indicate that the clock is off?
A valid time zone used to indicate that the clock isn't configured yet. It may be accurate to UTC, but the offset shouldn't be trusted.
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].
[1] https://en.wikipedia.org/wiki/Chronostasis
> 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!
> Later VCRs have that feature...
…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?
Asking one of the planet-killing oracles got me this:
https://www.researchgate.net/figure/The-XDS-Line-21-Time-Cod...
OS have millisecond uptime counters.
How does the OS know what a millisecond is without a clock?
…philosophically? Or technologically?
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.
the CPU itself uses a clock, that's why the speed is called clock speed!
Ah, the old VCR on a switched outlet mayhem. I don’t miss those days.
Sort of like Django defaulting to Chicago time.
For me, the latest django defaults to "TIME_ZONE = 'UTC'" in the settings.py.
"settings.py" is your local configuration. The global default is still Chicago:
* https://github.com/django/django/blob/main/django/conf/globa...
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.
I wonder what version they swapped it.
> to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC
...everything should be based on UTC though!
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.
That doesn’t answer the question of „What time does the calendar show once DST kicks in?“.
That’s up to the user’s preferences: their phone/computer’s timezone.
The meeting is at a different time in UTC when DST kicks in.
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?
If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. Further, what is displayed depends on the viewer's location (because daylight savings times change differently based on location/date). IOW, the time of the meeting occurs on TWO UTC times, not one. You can't just store UTC and be done with it. You need the originating timezone too. In other cases you may need the date the item was created as well.
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".
Tinder dates and market moves, maybe.
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.
CLOCK_MONOTONIC is affected by NTP skewing but should still always increase monotonically (i.e. never decrease)
What happens if someone makes an honest mistake (or is just malicious) and makes their NTP server run fast?
It's system dependent but Linux will generally speed up or slow down the time advancement until the delta from adjtime(...) matches up:
https://linux.die.net/man/2/clock_gettime
https://linux.die.net/man/3/adjtimeI am fairly certain POSIX define a day to be exactly 86400 seconds for the matter of calendar conversions/calculations, and deliberately ignores leap seconds: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1...
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.).
Trivia: a long time ago when an sqlite file was found on the iphone that has a full location history, some random HNer connected with me to make a web app that let the user see their location history if they uploaded their file.
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.
Sounds more like https://theweek.com/articles/624040/how-internet-mapping-gli...
That's turning locations into coordinates (ip geolocation). It's to be expected that the gps log only bases their logs on the coordinates from the GPS from the phone.
It'd be more practical to have a faraday cage and several GPS transmitters to spoof a location (let's say 33.783, -118.14899); turn on the device, if it tells you it's located at 33.783, -118.14899, then it's GPS receiver is working correctly, anywhere else, then there's something wrong...
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.
Probably don't even need a cage, GPS signals are so weak you could probably overpower them with even the weakest jammer/transmitter
My GPS location doesn't work in most buildings (with locating via WiFi turned off).
Is it easier to spoof GPS transmissions such that the phone will calculate it's at a specific coordinate? Rather than just check where they are reporting?
I thought that Russians used GLONASS, not the GPS.
If they're worried about someone guiding missiles with satnav, they are probably jamming those both plus the European one, would be my guess, or since they control their own GLONASS system they could be encrypting it if it supports that, or shutting it down in those areas.
There are 4 major global coverage ones plus the JP one (QZSS) and iirc also some recent Indian.
The major ones are GPS, Galileo, Glonass, Baidou.
Another fun "timezone" is the "Anywhere on Earth" designation referring to when a time has passed everywhere on Earth. It does not seem to be referenced in the IANA database though :)
https://en.wikipedia.org/wiki/Anywhere_on_Earth
We need some island nation to adopt a -72:00:00 time zone, so they people can book a flight there to beat deadlines defined as AoE.
And I thought this was a timezone to be used exclusively in factories - something like “always use utc on a server”, I thought this was meant to be used in factories!
Factory time zone is UTC+2 in the morning then switches to UTC-2 in the afternoon.
I see what you did there
I use UTC-15 as my factory timezone :)
Currently, no country uses that. And it has the nice property of making time go forward when it’s configured.
GM Island IRL. :D
As in WoW’s GM Island?
(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.)