4 ms·
The problem is not that the equality behavior is wrong, it’s that I would expect “utcnow()” to return a timestamp with a UTC timezone. The problem is that it do
by stingraycharles 4y ago
The problem is not that the equality behavior is wrong, it’s that I would expect “utcnow()” to return a timestamp with a UTC timezone. The problem is that it does not, it has no timezone at all, and therefor is generally less compatible than creating a timestamp with timezone from a utc timezone object.
I work on the Python API of a timeseries database and it’s very frustrating to have to accept timestamp objects without time zone because you don’t know what to do with them. People aren’t aware of this constraint, which leads to unexpected behavior.
- BiteCode_dev 4y agoDjango solves this by having the default timezone in the framework settings. Any datetime without a timezone is assumed to be using the default one. If you don't set a default timezone, the server timezone is used, and you are responsible for making sure your data is congruent.
- stingraycharles 4y agoYes I know, but that doesn’t help pretty much any of our Python users that are all heavily reliant on Pandas and/or definitely not writing web services. As of now, we just reject any timestamp without an explicit timezone and try to explain to our users why utcnow() is bad. People are generally very surprised that this issue exists at all.
- BiteCode_dev 4y agoYeah naive datetime should not even exist in high level API IMO. They're like bytes string with no encoding or geospatial data without a projection name field. It's going to bite you at some point.
- tpoacher 4y agoTimestamps do not have timezones. That's the whole point of a timestamp.
- adrian_b 4y agoTimestamps must have an implicit timezone, otherwise they are meaningless, because they cannot identify a certain moment in time. Only time differences do not have a timezone. When Python continues to use the word "timestamp" for a time value with an unknown time zone, then that is the fault of Python, because the name is completely inappropriate. I assume that whoever enabled a value "None" to be possible for the timezone did not really expect that anyone will ever use a timestamp with unknown timezone, but that in such cases there is a timezone known to the programmer, which is not stored with the timestamps, and that it is the responsibility of the programmer to restore the timezone whenever necessary.
- yakubin 4y agoIn this case we're talking about Unix timestamps though, which count the number of seconds since 1970 UTC. Adding a timezone to it is nonsensical. The number is always the same, no matter which timezone you're in. It's in the conversion to year-month-day, etc. that timezone becomes relevant.
- sokoloff 4y agoGP’s argument is that that means it has an implicit timezone of UTC.
- sanderjd 4y agoI would argue that "seconds since epoch in UTC" has an explicit timezone of UTC.
- BoiledCabbage 4y agoA point on the globe has a timezone. "Distance from London in feet" does not.
- mannykannot 4y ago
- 22c 4y agoI'd say the main issue here is that in the article, we have > ts = 1571595618.0 This a timestamp, there is no TZ data required. > x = datetime.utcfromtimestamp(ts) Now for some reason the developer cares about UTC all of a sudden? If the developer doesn't care about the TZ, they should use: datetime.fromtimestamp(ts)
- Aramgutang 4y agoA timestamp doesn't require TZ data because the timezone of the unix epoch is defined in UTC. To convert a timestamp into a meaningful datetime value, we need a timezone, otherwise there is loss of information. The main issue is that .utcfromtimestamp and .fromtimestamp both return naive datetimes, instead of aware ones with the timezone property set to UTC or the local timezone respectively.