4 ms·

> the software perspective of keeping up with DST is very costly. To be clear, the software perspective is to use Unix time instead.[0] [0] https://en.wikiped

> the software perspective of keeping up with DST is very costly. To be clear, the software perspective is to use Unix time instead.[0] [0] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time

imglorp 6y ago
Not really. Most machines use UTC internally (with varying epoch dates to represent it). And this is absolutely great until you need to interface with meatbags, ie local time. It's not just display of time either: think about anything Cron does in localtime, eg backups or open building door locks, or send an ACH payment file; then ponder all the corner cases of DST switches. Eg do you do something twice, or never? What if you reboot somewhere in the DST switch period? etc. All these shenanigans are dictated by the TZDB. Oh, and UTC also contains leap seconds.
- hunter2_ 6y ago
  I doubt anyone wants something to occur twice, but they might have an opinion on whether a 1:30am job should occur on the first 1:30am or the second 1:30am in the fall change. For the spring change, I think all jobs scheduled between 2am and 3am (a period that collapses into a moment) should ideally occur at said moment, but I can see how a smear might be more practical in many cases. I don't recall how `cron` and other schedulers handle it, though.
  - zwily 6y ago
    Every software service I’ve worked on has had issues around DST transitions. That’s really the only programming benefit I see for getting rid of it going forward.
    - disgruntledphd2 6y ago
      I worked at a big tech company for half a decade, and without fail, every year there was some kind of serious bug caused by DST. Things either happened twice or never, it was always really painful. In any growth company, I would imagine that these things keep occurring, as people haven't hit the bugs themselves yet.
- brandmeyer 6y ago
  > Most machines use UTC internally No, they rally aren't. Most machines use Posix time internally, and the fact that it doesn't reflect real-world leap seconds is a problem.
Jasper_ 6y ago
Unix time says nothing about which timezone you're in.
- jfax 6y ago
  I think that's the point
deleted 6y ago
[deleted]

imglorp 6y ago

Not really. Most machines use UTC internally (with varying epoch dates to represent it). And this is absolutely great until you need to interface with meatbags, ie local time. It's not just display of time either: think about anything Cron does in localtime, eg backups or open building door locks, or send an ACH payment file; then ponder all the corner cases of DST switches. Eg do you do something twice, or never? What if you reboot somewhere in the DST switch period? etc. All these shenanigans are dictated by the TZDB. Oh, and UTC also contains leap seconds.

hunter2_ 6y ago
I doubt anyone wants something to occur twice, but they might have an opinion on whether a 1:30am job should occur on the first 1:30am or the second 1:30am in the fall change. For the spring change, I think all jobs scheduled between 2am and 3am (a period that collapses into a moment) should ideally occur at said moment, but I can see how a smear might be more practical in many cases. I don't recall how `cron` and other schedulers handle it, though.
- zwily 6y ago
  Every software service I’ve worked on has had issues around DST transitions. That’s really the only programming benefit I see for getting rid of it going forward.
  - disgruntledphd2 6y ago
    I worked at a big tech company for half a decade, and without fail, every year there was some kind of serious bug caused by DST. Things either happened twice or never, it was always really painful. In any growth company, I would imagine that these things keep occurring, as people haven't hit the bugs themselves yet.
brandmeyer 6y ago
> Most machines use UTC internally No, they rally aren't. Most machines use Posix time internally, and the fact that it doesn't reflect real-world leap seconds is a problem.

Jasper_ 6y ago

Unix time says nothing about which timezone you're in.

jfax 6y ago
I think that's the point

deleted 6y ago

[deleted]