Paul Ganssle <b...@m.ganssle.io> added the comment: > from practical experience, it is a whole lot better to not deal with > timezones in data processing code at all, but instead only use naive UTC > datetime values everywhere, expect when you have to prepare reports or output > which has a requirement to show datetime value in local time or some specific > timezone.
This is not good advice. It is out of date, and has some significant pitfalls. See my blog post on the subject: https://blog.ganssle.io/articles/2019/11/utcnow.html If you are working with `datetime` objects that represent time in a specific time zone other than the system local zone, you should probably have them carry around a tzinfo object. > Note also that datetime.now() gives you a naive datetime. From an API > consistency standpoint I think it makes sense that datetime.utcnow() gives a > naive datetime. This... is not accurate. `.now()` gives you the local time; to the extent that they represent a date in a time zone at all, naïve time zones represent times in the *system local time*, which is why it makes sense for `.now()` to default to returning naïve time zones. For example, `datetime.now().timestamp()` will give accurate information, whereas `datetime.utcnow().timestamp()` will *not* (unless your local zone happens to be UTC or equivalent). > It would actually be confusing (IMO) for it to return an aware datetime. I > can see why you might disagree, but backward compatibility wins in this case > regardless. As evidenced by this thread, the fact that we have some APIs that return naïve datetimes generated by a process that treats them as localized datetimes in something other than system local times is actually the source of confusion 😛 That said, from a backwards compatibility point of view, we simply cannot change this. It has been proposed many times and it would be a major breaking change for almost no reason. The best we can do is to deprecate the offending methods and remove them. There is more information about the challenge that doing this would present in this datetime-SIG thread: https://mail.python.org/archives/list/datetime-...@python.org/thread/PT4JWJLYBE5R2QASVBPZLHH37ULJQR43/ I am sympathetic to the idea of removing it, but we would probably want to put some optimizations in place for `UTC` first, to make the transition more seamless in the few places where there are legitimate uses for `utcnow` and `utcfromtimestamp`. > I would argue that PEP20 should win over backward compatibility, in addition > to the points I hinted at above, practicality beats purity PEP 20 contains a bunch of contradictory advice, and it's not really a binding document anyway, so it definitely doesn't "win" over anything, but in this case you have it backwards. "Purity" would be making a breaking change for the purposes of making the function do what a lot of people think it does, but doing so would actually be impractical, because it would cause a lot of work for people, and create a lot of ambiguity in what people meant when they wrote a given line of code. The practical things to do here would be to either do nothing (not break anything that works and try and guide people away from using `utcnow` — maybe get a linting rule added to `pylint` to warn against it), or to deprecate and remove the function. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue12756> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
