Add tz kwarg to from_timestamp()

[Bibo-Joshi]

Closing #1613 as addendum to #1506

@tsnoam @plammens Is this, what was missing or am I overlooking half of it? :D

[plammens]

With this the default is an aware datetime, while before it was naive—e.g. telegram.Message.date will return an aware datetime. If we want Message.date and the like to keep being naive, the calls in the de_json of some telegram classes, e.g.

python-telegram-bot/telegram/message.py

Line 355 in 9344944

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

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

Otherwise I think the only problem is handling None: passing None to tzinfo will return a naive datetime in local rather than UTC. Maybe something like this instead:

if tzinfo is not None:
    return dtm.datetime.fromtimestamp(unixtime, tz=tzinfo)
else:
    return dtm.datetime.utcfromtimestamp(unixtime)

[Bibo-Joshi]

With this the default is an aware datetime, while before it was naive—e.g. telegram.Message.date will return an aware datetime. If we want Message.date and the like to keep being naive, the calls in the de_json of some telegram classes, e.g.

python-telegram-bot/telegram/message.py

Line 355 in 9344944

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

would also need to be changed to data['date'] = from_timestamp(data['date']).replace(tzinfo=None). Or the default for from_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 handling None: passing None to tzinfo will return a naive datetime in local rather than UTC. Maybe something like this instead:

if tzinfo is not None:
    return dtm.datetime.fromtimestamp(unixtime, tz=tzinfo)
else:
    return dtm.datetime.utcfromtimestamp(unixtime)

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

[Bibo-Joshi]

Updated as suggested. About the failing tests:

• Py2.7 fails because datetime has no timezone. 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 really have 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 🤔

[Poolitzer]

agree with the 2.7 part

[Bibo-Joshi]

@plammens Lost in translation … Thanks for clarifying!

[tsnoam]

one minor comment on a docstring. but LGTM, you can merge.

[tsnoam]

actually, i just fixed the docstring myself.

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