Contributor
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.
| data['date'] = from_timestamp(data['date']) |
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)
Member Author
With this the default is an aware
datetime, while before it was naive—e.g.telegram.Message.datewill return an awaredatetime. If we wantMessage.dateand the like to keep being naive, the calls in thede_jsonof sometelegramclasses, e.g.
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 forfrom_timestampcould 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: passingNonetotzinfowill 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.
Member Author
Updated as suggested. About the failing tests:
- Py2.7 fails because
datetimehas 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 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 🤔
Member Author
@plammens Lost in translation … Thanks for clarifying!
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one minor comment on a docstring. but LGTM, you can merge.
Member
actually, i just fixed the docstring myself.
you can merge from master and then you can merge this PR.
Closed
Closed
Merged
Closed
Merged
Closed
github-actions
Bot
locked as resolved and limited conversation to collaborators