6 ms·

Explanation from https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/EXQVDBTCYD4TR2QYQAY4726KDRYAJ6GT/ https://lists.iana.org/hyperkitty/list/tz@iana.org/

Explanation from https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/EXQVDBTCYD4TR2QYQAY4726KDRYAJ6GT/ 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.

wodenokoto 1y ago
So its a valid time zone used to indicate that the clock is off?
- jon-wood 1y 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 1y 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]. [1] https://en.wikipedia.org/wiki/Chronostasis https://en.wikipedia.org/wiki/Chronostasis
    - netsharc 1y ago
      > 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!
      - Horffupolde 1y ago
        OS have millisecond uptime counters.
        LgWoodenBadger 1y ago
        How does the OS know what a millisecond is without a clock?
        DaiPlusPlus 1y ago
        …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.
        yencabulator 1y ago
DaiPlusPlus 1y ago
> 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 1y 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 1y 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.
    - defrost 1y ago
      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.).
    - cluckindan 1y 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.
jgalt212 1y ago
Sort of like Django defaulting to Chicago time.
- echoangle 1y ago
  For me, the latest django defaults to "TIME_ZONE = 'UTC'" in the settings.py.
  - jgalt212 1y ago
    I wonder what version they swapped it.
  - throw0101a 1y ago
    "settings.py" is your local configuration. The global default is still Chicago: * https://github.com/django/django/blob/main/django/conf/global_settings.py#L41 https://github.com/django/django/blob/main/django/conf/globa...
    - echoangle 1y ago
      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.
xp84 1y ago
> 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.

wodenokoto 1y ago

So its a valid time zone used to indicate that the clock is off?

jon-wood 1y 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 1y 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]. [1] https://en.wikipedia.org/wiki/Chronostasis https://en.wikipedia.org/wiki/Chronostasis
  - netsharc 1y ago
    > 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!
    - Horffupolde 1y ago
      OS have millisecond uptime counters.
      - LgWoodenBadger 1y ago
        How does the OS know what a millisecond is without a clock?
        DaiPlusPlus 1y ago
        …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.
        yencabulator 1y ago

DaiPlusPlus 1y ago

> 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 1y 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 1y 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.
  - defrost 1y ago
    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.).
  - cluckindan 1y 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.

jgalt212 1y ago

Sort of like Django defaulting to Chicago time.

echoangle 1y ago
For me, the latest django defaults to "TIME_ZONE = 'UTC'" in the settings.py.
- jgalt212 1y ago
  I wonder what version they swapped it.
- throw0101a 1y ago
  "settings.py" is your local configuration. The global default is still Chicago: * https://github.com/django/django/blob/main/django/conf/global_settings.py#L41 https://github.com/django/django/blob/main/django/conf/globa...
  - echoangle 1y ago
    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.

xp84 1y ago

> 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.