3 ms·

> I don't want my equality operator doing timezone conversions Nobody argues for that. Especially since we’re comparing timestamps (floats), not datetimes (obj

> I don't want my equality operator doing timezone conversions Nobody argues for that. Especially since we’re comparing timestamps (floats), not datetimes (objects). Let’s go line by line : > ts = 1571595618.0 This is 2019-10-20 18:20:18.000 UTC > x = datetime.utcfromtimestamp(ts) I would therefore expect x to be 2019-10-20 18:20:18.000 UTC > x_ts = x.timestamp() I would therefore expect x_ts to be 1571595618.0. Which is surprisingly not. Nowhere the equality operator was involved in the surprise.

nly 4y ago
The comparison is being done between x_ts, which is a float, and x, which is a datetime object. Call be crazy but I think allowing this comparison to begin with is the problem. >>> from datetime import datetime >>> ts = 1571595618.0 >>> x = datetime.utcfromtimestamp(ts) >>> x_ts = x.timestamp() >>> type(x_ts) <class 'float'> >>> type(x) <class 'datetime.datetime'>
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- TotempaaltJ 4y ago
  The code in the first example says `ts == x_ts`, not `ts == x`.
  - nly 4y ago
    Argh.
- anttihaapala 4y ago
  That's not the code from the article. The code in the article is comparing 2 floats. Though, equality operator would return `False` for comparison `x == x_ts` as well, instead of throwing an exception.
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 ago
  I 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 ago
    It'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 ago
    Turns out the answer is what the article is all about.

nly 4y ago

The comparison is being done between x_ts, which is a float, and x, which is a datetime object. Call be crazy but I think allowing this comparison to begin with is the problem. >>> from datetime import datetime >>> ts = 1571595618.0 >>> x = datetime.utcfromtimestamp(ts) >>> x_ts = x.timestamp() >>> type(x_ts) <class 'float'> >>> type(x) <class 'datetime.datetime'>

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
TotempaaltJ 4y ago
The code in the first example says `ts == x_ts`, not `ts == x`.
- nly 4y ago
  Argh.
anttihaapala 4y ago
That's not the code from the article. The code in the article is comparing 2 floats. Though, equality operator would return `False` for comparison `x == x_ts` as well, instead of throwing an exception.

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 ago
I 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 ago
  It'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 ago
  Turns out the answer is what the article is all about.