6 ms·

I work in Arizona, and some of our software calls APIs on a server hosted in California. The California server expects timestamps in requests to be in Pacific t

by aezart 2y ago

I work in Arizona, and some of our software calls APIs on a server hosted in California. The California server expects timestamps in requests to be in Pacific time, with no timezone in the timestamp, and expects them to conform to daylight savings rules. This gets very hard to reason about because Arizona doesn't _do_ daylight savings. Like, what happens when we request 24 hours of data from them, on the day daylight savings time flips over? Do we want midnight-to-midnight data, or do we actually want 24 hours of data, which might wind up timestamped differently since there's a duplicate 2AM one day and a missing 2AM another day. A few years ago we had a contractor write some extremely messy code to handle cases like that, and soon it's going to be my job to try and refactor it into something readable.

Mountain_Skies 2y ago
It's surprising how many vendors of security product refuse to use UTC for timestamps and insist on using the local time of their bay area data center. The number of edge cases that arise from DST issues that are significantly reduced, if not completely eliminated, by using UTC should be reason enough for security product vendors to see it as a core best practice.
- swores 2y ago
  I'm amazed to hear anyone doesn't use UTC, I'm not a professional developer and I remember learning, just while teaching myself the basics of PHP & MySQL as a teenager, that it's best to have databases store either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) and to do the conversion to any local time zone wherever users interact with it.
  - josephg 2y ago
    I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. For example, we use roundabouts (traffic circles) everywhere here in Australia and google maps still gives pretty terrible directions when driving on them. I was shocked the first time I drove on the 101 just how good the spoken directions are - but it makes sense given the actual Google maps engineers drive that road. If the directions were bad there, they would get fixed. I shudder to think how many bugs must show up for people who use right-to-left languages or use non-ascii charsets - especially before Unicode & emoji were popular. I’m ashamed to admit I don’t even know how to test if my software works properly in languages like Arabic. Of course software made in the Bay Area assumes the whole planet uses pacific time. I’m sorry to throw shade, but that’s entirely in character for the area.
    - echelon 2y ago
      > I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. It's not just software. EVs struggle with cold and hot climates. They'll get better, of course. But with the engineers living in mostly temperate climates, conditions outside the development environment get less upfront attention.
  - oasisbob 2y ago
    The two worst offenders I can think of with regards to using local time were Rackspace, and Southwest Airlines. Not in the Bay Area, but every other west-coast company I've been involved with is pretty militant about using UTC, typically due battle wounds from communication challenges or time-related bugs. I would be very curious to hear which other major companies are deploying systems on local time in 2024.
    - fragmede 2y ago
      Google runs on Google Standard Time which is UTC+8 aka US west coast.
      - Timwi 2y ago
        No, it's UTC–8.
        fragmede 2y ago
        Yes, you're right. Thanks.
  - Izkata 2y ago
    > either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) UTC has leap seconds, unix timestamp doesn't. It's defined to have 86400 seconds per day, so there's no place to put a leap second. Instead, it either duplicates a timestamp or does "leap smearing" - slightly changing the duration of a second around where the leap second is.
    - deleted 2y ago
      [deleted]
    - AnotherGoodName 2y ago
      They both skip over leap seconds unlike TAI time, they just handle the leap second subtly differently. He’s right to say it’s essentially the same.
  - mypalmike 2y ago
    The most amazing of these exceptions is Microsoft Windows 11, which still uses local time on the hardware clock, a legacy of decisions made over 40 years ago. Raymond Chen defended this practice (20 years ago) https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37983 https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37... . It's possible to make it use UTC, but it requires registry hacking.
- galangalalgol 2y ago
  Why would anyone choose to use local time for anything other than display? That just seems way harder even if you don't have customers from other timezones.
  - mafuy 2y ago
    Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.
    - jiehong 2y ago
      True, but also for the past, actually. Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past. Same for dates a bit further back when countries changed calendars and some days are missing. So, we basically need a mapping of UTC -> local time as a function of time, and store this forever. (For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)
  - skissane 2y ago
    > Why would anyone choose to use local time for anything other than display? You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.
    - afiori 2y ago
      but school starts at 9am the nth of september not 2024-09-15 09:00:00
      - 2y ago

by aezart 2y ago

Mountain_Skies 2y ago

It's surprising how many vendors of security product refuse to use UTC for timestamps and insist on using the local time of their bay area data center. The number of edge cases that arise from DST issues that are significantly reduced, if not completely eliminated, by using UTC should be reason enough for security product vendors to see it as a core best practice.

swores 2y ago
I'm amazed to hear anyone doesn't use UTC, I'm not a professional developer and I remember learning, just while teaching myself the basics of PHP & MySQL as a teenager, that it's best to have databases store either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) and to do the conversion to any local time zone wherever users interact with it.
- josephg 2y ago
  I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. For example, we use roundabouts (traffic circles) everywhere here in Australia and google maps still gives pretty terrible directions when driving on them. I was shocked the first time I drove on the 101 just how good the spoken directions are - but it makes sense given the actual Google maps engineers drive that road. If the directions were bad there, they would get fixed. I shudder to think how many bugs must show up for people who use right-to-left languages or use non-ascii charsets - especially before Unicode & emoji were popular. I’m ashamed to admit I don’t even know how to test if my software works properly in languages like Arabic. Of course software made in the Bay Area assumes the whole planet uses pacific time. I’m sorry to throw shade, but that’s entirely in character for the area.
  - echelon 2y ago
    > I have a rule of thumb that software works progressively worse the further you are away from the Bay Area - both geographically and culturally. It's not just software. EVs struggle with cold and hot climates. They'll get better, of course. But with the engineers living in mostly temperate climates, conditions outside the development environment get less upfront attention.
- oasisbob 2y ago
  The two worst offenders I can think of with regards to using local time were Rackspace, and Southwest Airlines. Not in the Bay Area, but every other west-coast company I've been involved with is pretty militant about using UTC, typically due battle wounds from communication challenges or time-related bugs. I would be very curious to hear which other major companies are deploying systems on local time in 2024.
  - fragmede 2y ago
    Google runs on Google Standard Time which is UTC+8 aka US west coast.
    - Timwi 2y ago
      No, it's UTC–8.
      - fragmede 2y ago
        Yes, you're right. Thanks.
- Izkata 2y ago
  > either UTC or a Unix timestamp (which afaik is essentially the same as using UTC except that it's less easy for most people to read at a glance) UTC has leap seconds, unix timestamp doesn't. It's defined to have 86400 seconds per day, so there's no place to put a leap second. Instead, it either duplicates a timestamp or does "leap smearing" - slightly changing the duration of a second around where the leap second is.
  - deleted 2y ago
    [deleted]
  - AnotherGoodName 2y ago
    They both skip over leap seconds unlike TAI time, they just handle the leap second subtly differently. He’s right to say it’s essentially the same.
- mypalmike 2y ago
  The most amazing of these exceptions is Microsoft Windows 11, which still uses local time on the hardware clock, a legacy of decisions made over 40 years ago. Raymond Chen defended this practice (20 years ago) https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37983 https://devblogs.microsoft.com/oldnewthing/20040902-00/?p=37... . It's possible to make it use UTC, but it requires registry hacking.
galangalalgol 2y ago
Why would anyone choose to use local time for anything other than display? That just seems way harder even if you don't have customers from other timezones.
- mafuy 2y ago
  Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.
  - jiehong 2y ago
    True, but also for the past, actually. Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past. Same for dates a bit further back when countries changed calendars and some days are missing. So, we basically need a mapping of UTC -> local time as a function of time, and store this forever. (For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)
- skissane 2y ago
  > Why would anyone choose to use local time for anything other than display? You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.
  - afiori 2y ago
    but school starts at 9am the nth of september not 2024-09-15 09:00:00
    - 2y ago