Programming

16943 readers

888 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 1 month ago by [email protected] to c/[email protected]

6 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

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

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?

[–] pelya 1 points 1 month ago

You also have CLOCK_MONOTONIC, which could or could not be the number of seconds since last reboot.

To be honest, this mess was directly inherited from POSIX C system calls.