5 ms·

Sorry this happened to you, these kind of problems tend to be vague and difficult to patch up. I've advocated for over a decade as a systems engineer not to se

by kodah 4y ago

Sorry this happened to you, these kind of problems tend to be vague and difficult to patch up. I've advocated for over a decade as a systems engineer not to set system time to anything other than UTC. Not all languages or applications compensate for DST very well, and depending on your applications relationship with time it's a non-trivial problem to solve. What is far more trivial to do is to ship logs to a log server and let the UI of the log server translate time for the viewer of the logs. Almost every time I have argued with executives, managers, and SWEs without SE experience and lost something unexplainable and detrimental happens around DST. Edit: For the uninitiated I'll try to paint a clearer picture. All system time in Linux is tracked in seconds past Jan 1, 1970. The problem occurs in the translation between UTC and local time, which is handled by a library/package/module in your application. If your application is time sensitive and not looking for a literal time traveling event then things can get real weird, real fast. If there is a bug in that library/package/module things will also get real weird, real fast.

lionkor 4y ago
Apps shouldnt use anything but UCT for their timekeeping, there is no reason to do anything in the timezone's time. Setting the timezone should have no such effect.
- kodah 4y ago
  You and I can agree on that in principle but there's a lot of reasons an application may read from system time. If the application reads the wrong system time source, then they get unexpected time travel. Even things like the RTC can experience time travel under certain conditions. My point was, using anything other than UTC is just unnecessary complexity and often enough ends in complicated problems.
- lstamour 4y ago
  If your app interacts with humans or machines in other time zones, tracking in a different time zone can be necessary. Though often people don’t want to specify time zones with their complexities but instead specify times at locations. But I agree, generally your service doesn’t need time zones. The exception is necessary though when time zones get ambiguous or change (e.g. daylight savings going away)
joshspankit 4y ago
> All system time in Linux is tracked in seconds past Jan 1, 1970. > If your application is time sensitive and not looking for a literal time traveling event... One of my least-favourite facts is that these statements are misleading. Since Linux uses UTC and not TAI, it no longer tracks an absolute measurement of seconds since the unix epoch as it takes “leap seconds” in to account. As well, because of leap-seconds you can absolutely have time-travelling events. https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp https://developers.redhat.com/blog/2015/06/01/five-different...
- masklinn 4y ago
  > Since Linux uses UTC and not TAI Unix, not linux. I don’t even think they can track TAI, but I definitely have never seen one which does, they all define unix time as 86400*days since epoch + seconds since midnight.
  - bitcharmer 4y ago
    On Linux the clock_gettime syscall can absolutely return TAI with CLOCK_TAI

by kodah 4y ago

lionkor 4y ago

Apps shouldnt use anything but UCT for their timekeeping, there is no reason to do anything in the timezone's time. Setting the timezone should have no such effect.

kodah 4y ago
You and I can agree on that in principle but there's a lot of reasons an application may read from system time. If the application reads the wrong system time source, then they get unexpected time travel. Even things like the RTC can experience time travel under certain conditions. My point was, using anything other than UTC is just unnecessary complexity and often enough ends in complicated problems.
lstamour 4y ago
If your app interacts with humans or machines in other time zones, tracking in a different time zone can be necessary. Though often people don’t want to specify time zones with their complexities but instead specify times at locations. But I agree, generally your service doesn’t need time zones. The exception is necessary though when time zones get ambiguous or change (e.g. daylight savings going away)

joshspankit 4y ago

> All system time in Linux is tracked in seconds past Jan 1, 1970. > If your application is time sensitive and not looking for a literal time traveling event... One of my least-favourite facts is that these statements are misleading. Since Linux uses UTC and not TAI, it no longer tracks an absolute measurement of seconds since the unix epoch as it takes “leap seconds” in to account. As well, because of leap-seconds you can absolutely have time-travelling events. https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp https://developers.redhat.com/blog/2015/06/01/five-different...

masklinn 4y ago
> Since Linux uses UTC and not TAI Unix, not linux. I don’t even think they can track TAI, but I definitely have never seen one which does, they all define unix time as 86400*days since epoch + seconds since midnight.
- bitcharmer 4y ago
  On Linux the clock_gettime syscall can absolutely return TAI with CLOCK_TAI