• @[email protected]
    link
    fedilink
    English
    173 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
      link
      English
      63 months ago

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

      • @[email protected]
        link
        fedilink
        33 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.

      • @bitchkat
        link
        English
        13 months ago

        An Instant represents single point on the universal time line. This can always be converted to LocalTime and vice versa. For periodic jobs, you calculate the next occurrence in the local time and then save it as an Instance (UTC).

    • Scrubbles
      link
      fedilink
      English
      53 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
      link
      English
      4
      edit-2
      3 months ago

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