4 ms·

> 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.
    - grodriguez100 1y ago
      CLOCK_MONOTONIC is affected by NTP skewing but should still always increase monotonically (i.e. never decrease)
      - DaiPlusPlus 1y ago
        What happens if someone makes an honest mistake (or is just malicious) and makes their NTP server run fast?
        kevindamm 1y ago
        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/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. https://linux.die.net/man/3/adjtime https://linux.die.net/man/3/adjtime 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.
  - Joker_vD 1y ago
    I 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_chap04.html#tag_04_19 https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1...
rtpg 1y ago
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
eirikbakke 1y ago
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?
- DaiPlusPlus 1y ago
  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.
  - Hackbraten 1y ago
    That doesn’t answer the question of „What time does the calendar show once DST kicks in?“.
    - DaiPlusPlus 1y ago
      That’s up to the user’s preferences: their phone/computer’s timezone.
      - pbh101 1y ago
        The meeting is at a different time in UTC when DST kicks in.
        DaiPlusPlus 1y ago
        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?

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.
  - grodriguez100 1y ago
    CLOCK_MONOTONIC is affected by NTP skewing but should still always increase monotonically (i.e. never decrease)
    - DaiPlusPlus 1y ago
      What happens if someone makes an honest mistake (or is just malicious) and makes their NTP server run fast?
      - kevindamm 1y ago
        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/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. https://linux.die.net/man/3/adjtime https://linux.die.net/man/3/adjtime 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.
- Joker_vD 1y ago
  I 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_chap04.html#tag_04_19 https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1...

rtpg 1y ago

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

eirikbakke 1y ago

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?

DaiPlusPlus 1y ago
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.
- Hackbraten 1y ago
  That doesn’t answer the question of „What time does the calendar show once DST kicks in?“.
  - DaiPlusPlus 1y ago
    That’s up to the user’s preferences: their phone/computer’s timezone.
    - pbh101 1y ago
      The meeting is at a different time in UTC when DST kicks in.
      - DaiPlusPlus 1y ago
        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?