With this the default is an awaredatetime, while before it was naive—e.g.telegram.Message.date will return an awaredatetime. If we wantMessage.date and the like to keep being naive, the calls in thede_json of sometelegram classes, e.g.

Otherwise I think the only problem is handlingNone: passingNone totzinfo will return a naive datetime inlocal rather than UTC. Maybe something like this instead:

iftzinfoisnotNone:returndtm.datetime.fromtimestamp(unixtime,tz=tzinfo)else:returndtm.datetime.utcfromtimestamp(unixtime)

With this the default is an awaredatetime, while before it was naive—e.g.telegram.Message.date will return an awaredatetime. If we wantMessage.date and the like to keep being naive, the calls in thede_json of sometelegram classes, e.g.

python-telegram-bot/telegram/message.py

Line 355 in9344944

data['date']=from_timestamp(data['date'])

would also need to be changed todata['date'] = from_timestamp(data['date']).replace(tzinfo=None). Or the default forfrom_timestamp could be kept as naive UTC to avoid the breaking change.

Good point. Let's wait, what tsoam says.

Otherwise I think the only problem is handlingNone: passingNone totzinfo will return a naive datetime inlocal rather than UTC. Maybe something like this instead:

iftzinfoisnotNone:returndtm.datetime.fromtimestamp(unixtime,tz=tzinfo)else:returndtm.datetime.utcfromtimestamp(unixtime)

Oh, shuh, you're absolutely right. Will update tonight.

Updated as suggested. About the failing tests:

• Py2.7 fails becausedatetime has notimezone. But since this PR is only due for v12.5, which I reckon won't be released bevore 2020, when we drop Py2.7, I guess we don't reallyhave to adjust for that. Although, I wonder why it didn't fail on the first run …
• As usual, I have no clue, what codecov wants from me 🤔

agree with the 2.7 part

@plammens Lost in translation … Thanks for clarifying!

actually, i just fixed the docstring myself.

you can merge from master and then you can merge this PR.