• carrylex@lemmy.worldOP
    2·
    2 months ago

    So just for additional context:

    This meme was brought to you by the following API response scheme:

    {
  "time": "2007-12-24 18:12",
  "servertimezone": "Europe/Vienna",
  "timezoneoffset": -8
}

    when it could have just been

    {
  "date": "2007-12-24T18:21:00-07:00"
}
  • ByteJunk@lemmy.world
    1·
    2 months ago

    It should be implemented in people’s brains.

    How this goes, usually, is:

    Them:…before 6PM.

    Me: 6PM… Ours? The server’s? The user’s?

    Them: GMT, of course.

    Me: So that’s 7PM London right now, and changes to 6PM in November?

    Them: What no are you stupid. Always 6PM GMT.

    Me:* jumps off a cliff*

      • Ephera@lemmy.ml
        1·
        2 months ago

        GMT doesn’t have daylight savings, but most people won’t be as precise in language. Here in Germany, we might also tell people “GMT+2”, even though it changes to GMT+1 in winter. Like, I don’t even know what the correct shorthand would be for our timezone…

    • mox@lemmy.sdf.org
      1·
      2 months ago

      Them: GMT, of course.

      Me: So that’s 7PM London right now, and changes to 6PM in November?

      Them: What no are you stupid. Always 6PM GMT.

      Me:* jumps off a cliff*

      Sorry, but are you under the impression that GMT means London time, or that it observes British Summer Time?

    • Klear@lemmy.world
      1·
      2 months ago

      Reminds me of a LARP I was on one time. A group of people I was doing stuff with ended up always meeting at 10 because we redefined “10” to mean “whenever we all meet”.

  • GTG3000@programming.dev
    0·
    2 months ago

    Anything an API returns should just look like 1720533944.963659 .

    There’s no reason to store dates as anything other than UTC. User-side, sure, timezones are useful. Server doesn’t have to know.

    • Zagorath@aussie.zoneEnglish
      1·
      2 months ago

      This is absolutely fundamentally wrong. What you’ve described is what Nodatime calls an Instant, and it’s a very important data class, but there are valid reasons to use other classes.

      A LocalDateTime cares about the date and time locally. An event scheduled for 8am every Monday might use this. It would update accordingly if you move locations to a new locale.

      A ZonedDateTime can almost be directly translated into an Instant, except that one time zone might change. If you go into or out of daylight saving time, or your region decides to change its time offset. Oslo time is still Oslo time. You use this if your event occurs at a specific time in a specific location.

      An OffsetDateTime is like a ZonedDateTime, but instead of being tied to a specific time zone (e.g. “Oslo time”) it’s tied to a specific UTC offset (e.g. UTC+1).

      You don’t have to use Nodatime, but you should at least think deeply about what your time objects actually represent and what is the best way to represent them.

      See the creator of Nodatime’s presentation about thinking deeply about time for more.