Naive datetime should be treated as local timezone. UTC datetimes should be timezone aware.

[n5y]

Caused by #1506(#1505) #1485(#1362)

I believe local timezone is the expected default for naive datetime objects. Breaking those expectations will lead to unnecessary surprises for the users. It will also lead to awkward conversions if another library that does follow this convention is used.

Python's datetime.fromtimestamp and datetime.astimezone assume local timezone for naive objects. There are three warnings in datetime docs that start with "Because naive datetime objects are treated by many datetime methods as local times, it is preferred to use aware datetimes to represent times in UTC."

Using utc time is surely more sane than using local time, but the better way to do that is timezone aware datetimes, not naive-utc datetimes. For example Message.date should be timezone aware.

[Bibo-Joshi]

As of #1621 (released in v12.7), helpers.from_timestamp returns an aware object. Therefore I see this issue as resolved and will close.
If I'm missing the point and/or you disagree, feel free to comment.

[n5y]

I disagree, that pull request only addressees the second sentence from the issue title. Using aware datetimes removes the need to use "naive-utc", but at the moment naive datetimes are still treated as utc by the library.

On a side note: update.message.date changing from naive to aware is a breaking change and is not really explained in release notes.

[Bibo-Joshi]

Sorry, I don't really understand what you mean by "but at the moment naive datetimes are still treated as utc by the library." Or are you talking about JobQueue?

I'll update the changelog.

[n5y]

I'm talking about datetime objects being provided by a user. I guess it's only relevant to job queue stuff at the moment. It also affects any future methods that will accept a datetime/time from a user, since those methods will probably use the same helpers.

[Bibo-Joshi]

Mh okay. E.g. send_polls close_date and kick_chat_members until_date would also fall into that category. Didn't have that in mind. Fair enough, I'll reopen.

Just FYI: We're planning on adding tzinfo to the Defaults logic, which would allow to interpret all naive date/time objects in the library as a customized timezone. I know that's not exactly what you proposed, but it would make it easy to have everything interpreted as local timezone. (See #1797 )

[Bibo-Joshi]

We discussed this again internally and decided to stick with the way it is now, i.e. tread naive datetimes as UTC by default.