• azvasKvklenko@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    3
    ·
    3 months ago

    It’s only bad when used incorrectly. Just store time in UTC and convert it to timezone of your setting to present it. Most modern languages offer a library that makes it just one more line of code. Not only it’s then clear and unambiguous, it supports all timezones.

    • dvlsg@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      3 months ago

      Doesn’t always work, especially if you need to work with any sort of calendar or recurring schedule.

      • booly@sh.itjust.works
        link
        fedilink
        arrow-up
        3
        ·
        3 months ago

        Yeah, timestamps should always be stored in UTC, but actual planning of anything needs to be conscious of local time zones, including daylight savings. Coming up with a description of when a place is open in local time might be simple when described in local time but clunkier in UTC when accounting for daylight savings, local holidays, etc.

    • Scrubbles@poptalk.scrubbles.tech
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      1
      ·
      3 months ago

      bingo. Timezones became easier when I learned that all apps and databases should have all times be in UTC. Let the UI do it’s thing and accept local time and convert it, and vis versa.

    • TCB13@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      3 months ago

      +1 for this. This is kinda the same issue with encoding, just UTF-8 everything and move on.