689
Implementing RFC 3339 shouldn't really be that hard... (lemmy.world)
submitted 4 months ago by carrylex@lemmy.world to c/programmer_humor@programming.dev
83 comments fedilink hide all child comments

Template

Further reading: RFC 3339 / ISO 8601

you are viewing a single comment's thread
view the rest of the comments
[-] umbraroze@lemmy.world 3 points 4 months ago

Not exactly boned but it probably doesn't make practical difference to store "local time + tzinfo timezone" than just UTC time.

  • You record an event occurring at local time
  • You store it as UTC
  • Local time zone definition changes
  • Well whoop de loo, now you need to go through tzinfo to make sense of the past data anyway rather than relying on a known offset

Even if you store everything in UTC, you may be safe... but figuring out the local time is still convoluted and involves a trip through tzinfo.

[-] booly@sh.itjust.works 5 points 4 months ago* (last edited 4 months ago)

I think the comment is specifically talking about storing future times, and contemplating future changes to the local time zone offsets.

If I say that something is going to happen at noon local time on July 1, 2030 in New York, we know that is, under current rules, going to happen at 16:00 UTC. But what if the US changes its daylight savings rules between now and 2030? The canonical time for that event is noon local time, and the offset between local time and UTC can only certainly be determined with past events, so future events defined by local will necessarily have some uncertainty when it comes to UTC.

this post was submitted on 08 Jul 2024
689 points (98.6% liked)

Programmer Humor

19564 readers
513 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev