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.
netsharc · 4m ago
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.
> 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.
jgalt212 · 49m ago
Sort of like Django defaulting to Chicago time.
echoangle · 39m ago
For me, the latest django defaults to "TIME_ZONE = 'UTC'" in the settings.py.
wodenokoto · 3h ago
So its a valid time zone used to indicate that the clock is off?
jon-wood · 3h ago
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.
DaiPlusPlus · 1h ago
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].
> to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC
...everything should be based on UTC though!
defrost · 1h ago
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.
poly2it · 1h ago
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.
cluckindan · 53m ago
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.
grodriguez100 · 32m ago
CLOCK_MONOTONIC is affected by NTP skewing but should still always increase monotonically (i.e. never decrease)
DaiPlusPlus · 21m ago
What happens if someone makes an honest mistake (or is just malicious) and makes their NTP server run fast?
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.).
Towaway69 · 2h ago
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!
bravesoul2 · 2h ago
Factory time zone is UTC+2 in the morning then switches to UTC-2 in the afternoon.
randyrand · 31m ago
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.
taneq · 2h ago
GM Island IRL. :D
jonathanlydall · 2h ago
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.)
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.
> 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.
...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
...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.
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.).
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.)