4 ms·
This is just dumb... > I would have made it more clear that these functions work with naive time, maybe by calling them naive_utcnow() and naive_utcfromtimesta
by hanniabu 3y ago
This is just dumb...
> I would have made it more clear that these functions work with naive time, maybe by calling them naive_utcnow() and naive_utcfromtimestamp().
> But their names are not the problem here. The specific issue is that some Python date and time functions accept naive timestamps and assume that they represent local time, according to the timezone that is configured on the computer running the code.
Uhhh, no I would not expect local time because as the name entails we're dealing in UTC. Sigh.....
- vore 3y agoYou might not, but the standard library sure does. And that's the exactly the problem! How can functions in the standard library know if the time is local or UTC without any indication on the value itself? (spoiler: they can't!)
- BugsJustFindMe 3y agoThe less stupid solution is to just make those functions produce zone aware datetimes because you have literally asked for a specific time zone.
- seanp2k2 3y agoAs the article author correctly points out, Python should have just thrown when a method is called that requires a TZ with a datetime that doesn’t include one. Between this, the Unicode circus, and the rejection of PEP582, Python seems more and more like the HOA that isn’t earning their monthly fees IMO.