> Er, not really. Not meaningfully. They can be freely compared with timezone-aware timestamps
Author here. My original post was a little ambiguous on this topic; I've updated it to make it clearer.
The tl;dr is that in Python, `time.time()` calls the c stdlib `time` function (at least in CPython), which follows the POSIX standard. It turns out that POSIX standard does _not_ mention timezones at all: https://pubs.opengroup.org/onlinepubs/9699919799/functions/t...
To wit, you can't actually assume that timestamps are UTC in Python, which is a different kind of insanity:
> To wit, you can't actually assume that timestamps are UTC in Python, which is a different kind of insanity:
The code you’ve put in this comment is some… utter nonsense, sorry! Not sure how else to put it. And you’ve come to a wrong conclusion as a result. And the wrong conclusion does not even make sense.
When you call .replace(), you’re constructing the Toronto time which has the same local time as the current UTC time. This MUST have a different timestamp than the current UTC time.
Basically, it is 5:00 PM right now in Toronto, UTC-4, which is 9:00 PM UTC. Your code is “Give me the current local time UTC (9:00 PM), replace the time zone with Toronto (9:00 PM Toronto), and then give me the timestamp for that.” The result is nothing more than a timestamp four hours in the future. You’ve managed to construct a sequence of API calls that adds four hours to the current time.
Some problems:
1. You SHOULD know better than to call .utcnow(). When you try it, Python will print out this message:
> DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
2. In general, .replace() CHANGES the datetime object into a different one, which represents a different moment in time. If you want the same moment in time but a different time zone, you want .astimezone(), which gives you the SAME moment in time, but with a different timezone.
3. Timestamps are safe to compare. They represent instants in time and you do not need to worry about timezone conversions when you work with timestamps.
4. The notion that “you can't actually assume that timestamps are UTC in Python” is nonsensical, because timestamps don’t have timezones! A timestamp isn’t UTC in the first place. It simply represents an instant in time.
I really think there are some fundamental misconceptions at work here. I am hoping that this comment will help bust some of your misconceptions and help you arrive at a more correct understanding of how time works:
- datetime objects can be timezone naïve or timezone aware,
- timestamps are in an entirely separate category, where timezones do not matter at all.
I recommend looking at something like Java’s JSR-310 library for more information about how a well-designed API would look. In particular, think about how Instant, LocalDateTime, OffsetDateTime, and ZonedDateTime map to Python classes. The Java classes are more strict in their semantics and can serve somewhat as a point of reference for how you “should” think about time.
Author here. My original post was a little ambiguous on this topic; I've updated it to make it clearer.
The tl;dr is that in Python, `time.time()` calls the c stdlib `time` function (at least in CPython), which follows the POSIX standard. It turns out that POSIX standard does _not_ mention timezones at all: https://pubs.opengroup.org/onlinepubs/9699919799/functions/t...
To wit, you can't actually assume that timestamps are UTC in Python, which is a different kind of insanity:
``` datetime.datetime.utcnow().replace(tzinfo=pytz.timezone("America/Toronto")).timestamp() ```
differs materially from
``` datetime.datetime.utcnow().timestamp() ```