1. The reason they existed in the first place was as a convenience when there were no concrete time zone types in the standard library.
Also because the machine has two datetime you might want to work with: UTC and whatever time zone the locale thinks it’s in. And either way, you may want a naive datetime.
There are many more types of datetime you may want to work with.
I don't see any particularly compelling reason to use naive
datetimes to represent UTC when there is very little support for
that in the language itself, and there is direct support for using
aware time zones for this.
“Local” is as poorly defined, and more likely to be misinterpreted, as “naive”. Local to the machine the code is running on? Local to the user? Local to the data the user is working with?
In this case it is not poorly defined, it specifically
means the context of the system time. I was not saying that I
think naive datetimes should represent local time, I'm
saying that whenever a naive datetime is treated as representing a
specific time (as opposed to an abstract datetime for calendrical
operations), it is interpreted as a system-local time.
So if your local time is set to America/New_York, then you get:
In : dt = datetime(2019, 4, 15,
In : print(dt)
This is the bug at the root of Brock's original issue, and it's one reason why using naive datetimes to represent a specific time zone is somewhat perilous.
Like I said, I don't really feel strongly about breaking backwards compatibility to doing this, but I do dispute that it is "very useful". It creates an implicit assumption about what the datetime represents that is contrary to what the language itself assumes and there's already a perfectly good mechanism for making those assumptions explicit - attaching the timezone.utc object to the datetime.
The one advantage `datetime.utcnow()` has is that it is somewhat faster than `datetime.now(tz=timezone.utc)`Using a naive datetime for UTC is still very useful, I’d like to keep an easy, backward compatible way to get it.