• @Daxtron2
    link
    53 months ago

    Store times in UTC, convert in UI to locale’s timezone with one of any of the millions of timezone libraries. If you’re storing in local time, you’re gonna have a bad time.

    • @ShortFuse@lemmy.world
      link
      fedilink
      1
      edit-2
      3 months ago

      Timestamp in UTC

      But for time of day, use local time and store separate column with the timezone name. Don’t use timezone offsets since that doesn’t work with DST. You’re better off with something like America/New_York because God knows what 2030 will look like.

      And if timezone are abolished, or DST, that’s even more reason to store the timezone name.

      • @Daxtron2
        link
        13 months ago

        Yes that’s true, I just go by whatever ISO standard

    • @Phrodo_00@lemmy.world
      link
      fedilink
      13 months ago

      It depends. If something needs to happen in local time (like, always at the same time regardless of daylights savings for example) you should be storing times in local timezone

      • @Daxtron2
        link
        23 months ago

        Store in UTC with the tz offset and if you’re using a modern tz library, that should handle it for you.

        • @Phrodo_00@lemmy.world
          link
          fedilink
          13 months ago

          tz offset is really not enough. You’d need to save the time zone id and/or offset, to have you library calculate deviations such as daylight savings.

          Even that, that would break if the user moves and now what they setup is using their previous timezone.

          Basically, I’m saying that storing the offset works most of the time, but not all of the time.

          • @Daxtron2
            link
            13 months ago

            Yeah that’s true, tzid is probably better than just a straight offset, that’s probably what I was thinking but it was late when I posted lol. And the user moving is really more an issue of making updating that accessible imo