this post was submitted on 17 Jul 2024
26 points (96.4% liked)

Programming

17319 readers
150 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
26
A Python Epoch Timestamp Timezone Trap (nerderati.com)
submitted 3 months ago by roadrunner_ex@lemmy.ca to c/programming@programming.dev
7 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] xmunk@sh.itjust.works 3 points 3 months ago (1 children)

Honestly, I'm working on a system with data we control and we've been migrating pg columns from WITHOUT to WITH TIMEZONE - our server natively runs in PST rather than UTC for convenience and everytime we find a naive timestamp we have two main options to consider - whether the dev properly stored values as UTC or whether they just used a now like function and got PST.

[–] litchralee@sh.itjust.works 2 points 3 months ago (1 children)

I have to ask: does your server switch to storing PDT during daylight savings? Either way, I'm so sorry you have to deal with that.

[–] xmunk@sh.itjust.works 3 points 3 months ago

So all of our dates should be stored in UTC... but everytime we have to deal with an unmarked column we have to check if it's in PST because a developer forgot. If a developer did forget, they'd probably grab the PDT value during DST.