Programming

17426 readers

215 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

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 [email protected]

founded 1 year ago

MODERATORS

[email protected]

A Python Epoch Timestamp Timezone Trap (nerderati.com)

submitted 4 months ago by [email protected] to c/[email protected]

6 comments fedilink hide all child comments

top 6 comments

sorted by: hot top controversial new old

[–] [email protected] 3 points 4 months ago

The return value of time.time() is actually a floating-point number ... It's also not guaranteed to be monotonically increasing, which is a whole other thing that can trip people up, but that will have to be a separate blog post.

Oh god, I didn't realize that about Python and the POSIX spec. Cautiously, I'm going to guess that GPS seconds are one of the few reliable ways to uniformly convey a monotonically-increasing time reference.

Python has long since deprecated the datetime.datetime.utcnow() function, because it produces a naive object that is ostensibly in UTC.

Ok, this is just a plainly bad decision then and now by the datetime library people. What possible reason could have existed to produce a TZ-naive object from a library call that only returns a reference to UTC?

[–] [email protected] 2 points 4 months ago (1 children)

For what it's worth, I have been a convert from naive to aware for a couple years now. I used to like to think naive == UTC, but when data comes from unverifiable sources, you can't know that for certain...

[–] [email protected] 3 points 4 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.

[–] [email protected] 1 points 4 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.

[–] [email protected] 2 points 4 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.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

Professionals have standards. (implying that Python is not professional, mind you I love Python and use it since a decade)