1. 17

  2. 7

    Don’t forget that these things change pretty regularly too, and not all time zone data is updated at the same time. Had a good one recently: Brazil got rid of daylight savings time a few weeks ago. We had a job the is queued with a Postgres query but has a sanity check before executing that uses @js-joda/timezone, which was updated almost immediately. So the job queued an hour before it was supposed to be sent because the Postgres timezones hadn’t been updated yet. It completed an hour later but it was quite a head scratcher.

    1. 1

      Oh man, that sucks.

      All of Brazil, or only some states? What was the lead time?

      I deal with timezone/DST at work. Luckily (?) we no longer have any customers in Brazil.

      1. 2

        It was all of Brazil although I think we only had one customer affected, in Sao Paolo. Lead time was… less than you would expect? The news certainly didn’t make it to us before this incident at least.

        I am continually amazed at how damned confusing timezones can be, even when using good libs and knowing wha you’re doing. It’s always a brain teaser when converting in your head from where you are to where the code will be running to where the client will be running.

    2. 3

      It’s not totally clear what’s going on here:

      This code was deployed, and, what a surprise, I got the error: 2019-09-08 is an invalid time. – Huh, what do you mean the time is invalid?

      Where’d that data come from in the first place?

      If you use tzinfo aware code everywhere, you’re not as likely to run into this stuff, if you keep your DB up to date.