Praise the sun!

  • bamboo@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 months ago

    What sorts of issues? It’s been common for decades to store time in UTC, and render local time on the client side.

    • Spider@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      Not the person you responded to , but the “render local time on the client side” is the tricky part, especially when the time is in the past or future relative to current. Theres a hundred edge cases to consider and many of them very non-obvious to our feeble linear time oriented mortal minds.

    • Carighan Maconar@piefed.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      So as s simple example from the system I work with:

      Customers can set rolling validities for alerts, e.g., Monday 8-10.

      If a customer from a place which currently has DST puts in 8-10 say, CEST, in their browser (6-8 UTC) then they intuitively expect this to still be 8-10 their local time (7-9 UTC) when later winter time rolls around.

      But, all data checked for alerts comes in in UTC and different users editing these validities are from different countries, timezones and summer time preferences.

      Gets funky really quickly. Especially because the evaluation has to account for the DST shift essentially on a per-recipient DST when configured vs DST when evaluated basis. (This is genuinely a simple example, it gets worse 😁)