- Joined
- Feb 15, 2014
- Messages
- 20,194
Hard to say without a debugger, but some spelunking suggests that the snapshot tuple is carrying around a tzinfo object, in addition to the datetime - which feels weird to me, but I'm not reading the whole source, so it might make sense. No judgement here when it comes to time zones.
utcnow() seems to return a naïve object, the canonical way to get UTC with the TZ info attached is with now( timezone.utc ).
In this case everything should work nicely once the tzinfo is consistently employed. Both parameters to the function are datetime.datetime objects, (well, one of them is a namedtuple which has a datetime element which is the object used here, but whatever) and as such overload the + and - operators according to a couple of rules which mostly make intuitive sense:
| datetime2 = datetime1 + timedelta | (1) |
| datetime2 = datetime1 - timedelta | (2) |
| timedelta = datetime1 - datetime2 | (3) |
| datetime1 < datetime2 | Compares datetime to datetime. (4) |
timedelta and datetime are both classes of the datetime module, which gets confusing at first if you don't read the docs carefully or have someone tell you that bit. So in this case we have:
datetime < datetime - timedelta <-> datetime < datetime
The latter of which is straightforward to most humans.
I work a lot with satellite data, so I have the benefit of being able to say "ok, everything is UTC internally, if there's ever a need for non-UTC, that's an I/O detail" (shamelessly copying the Apollo Guidance Computer's use of SI units for all calculations, with conversions from customary aerospace units done for I/O purposes for the crew's benefit).
