3 ms·
If I’m calling .utcfromtimestamp then by the name I expect it to be doing _more_ than just attaching a time zone (which it also doesn’t do). The only other beha
by misnome 4y ago
If I’m calling .utcfromtimestamp then by the name I expect it to be doing _more_ than just attaching a time zone (which it also doesn’t do). The only other behaviour that seems sensible is that it’s doing… some sort… of conversion. Exactly what I’d need to look up at the time I wanted to use it.
I have, however, been using python so long that I’ve gotten used to the way things sort-of-work and developed such a healthy caution around it’s unintuitive built-in time zone handling.
- lostmsu 4y agoI wasn't aware about the functions until this thread, and my expectations match the grandparent. Why is ts not equal to x_ts?
- misnome 4y agoIt's actually worse than I had initially suspected. Pythons' dateutil timezone handling is, depending on your opinion, either hard to reason about or just outright broken - certainly it tries to be clever in unintuitive ways. This is why there is a couple of external libraries, like dateutil to try and make timezone things easier - which is even mentioned at the beginning of pythons' datetime documentation! In this case, I believe that it's actually the inverse from what I thought - utcfromtimestamp is doing... nothing; but is different by the fact that nothing is different from everything else. It looks like .fromtimestamp builds a "naive" datetime in local time. So, it assumes the timestamp is UTC and "helpfully" converts it to the local date and time. When you do .timestamp it inverses this process and gives you back the timestamp value in UTC by converting implicitly from your local time zone. Thus, if you do .utcfromtimestamp it doesn't do this conversion, and gives you a naive datetime "in UTC". This is horrible and I fully support the recommendation never to use it.
- lostmsu 4y agoTurns out the answer is what the article is all about.