3 ms·

The majority of programmers should never be directly coding to account for DST but instead should be using libraries (JodaTime, moment.js) that abstract local t

The majority of programmers should never be directly coding to account for DST but instead should be using libraries (JodaTime, moment.js) that abstract local time differences. There are just too many to keep track of. I'm glad I don't have to worry about code I wrote 5 years ago handling the end of DST in Florida.

jedberg 9y ago
As an engineer I always use a library, or set up systems on Arizona time so I don't have to deal with it. But I often had to work with systems/software made by other people who made a lot of assumptions about dates.
- styfle 9y ago
  Why Arizona time? Isn’t it easier to use UTC?
  - jedberg 9y ago
    I live and work in California, so it's way easier in my head to subtract one hour during the few winter months we're on standard time, and then not have to do any math from March to October. UTC always requires a bunch of mental gymnastics to subtract 7 or 8.
    - styfle 9y ago
      It’s possible for Arizona to start using DST in the future. Indiana used to not observe DST until 10 or 15 years ago.
curun1r 9y ago
Even with libraries, DST creates headaches. Just having an hour of ambiguous time (Nov 4, 1:23am 2018 has two possible meanings in most places) means having to write test cases, parse log files differently and there are areas (e.g. database) where you can't use a library and if you're not able to structure your application to store UTC timestamps, you have to account for it yourself. Libraries are great at abstracting away a lot of the pain, but some of the complexity will always leak through that abstraction.