-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent use of UTC/local naïve datetimes #1505
Labels
Comments
Yes, I think putting the time-handling overhaul in a separate PR would be good. |
Ok. By #1409 (comment), I understand we want the standard for naïve |
plammens
added a commit
to plammens/python-telegram-bot
that referenced
this issue
Sep 4, 2019
(cherry-picked from c6dd3d7. I've included the refactoring mentioned in python-telegram-bot#1497 to facilitate the change.) There was inconsistent use of UTC vs local times. For instance, in the former `_timestamp` helper (now `_datetime_to_float_timestamp`), assumed that naive `datetime.datetime` objects were in the local timezone, while the `from_timestamp` helper —which I would have thought was the corresponding inverse function— returned naïve objects in UTC. This meant that, for instance, `telegram.Message` objects' `date` field was constructed as a naïve `datetime.datetime` (from the timestamp sent by Telegram's server) in *UTC*, but when it was stored in `JSON` format through the `to_json` method, the naïve `date` would be assumed to be in *local time*, thus generating a different timestamp from the one it was built from. See python-telegram-bot#1505 for extended discussion.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
PR #1485 made
telegram.utils.helpers.from_timestamp
return a naïvedatetime.datetime
object in UTC, but this created an inconsistency with the rest of the repository in the handling of naïvedatetime.datetime
s, where it is assumed that these objects represent local time. In fact, there is a direct inconsistency betweenfrom_timestamp
andto_timestamp
helpers, since the latter still assumes that thedatetime
object is in local time.See #1497 (comment) (point
3.
) for extended discussion.I've already fixed the issue in #1497 (and added tests), but should I make a separate PR to isolate the change?
Steps to reproduce
Go to a place with nonzero UTC offset. I live in CEST (GMT +2).
Construct a
telegram.Message
from a JSON data dictionary. This is a message I sent to a test bot of mine (stripped of the optional fields), as received from an HTTP request to Telegram:Re-form the
Message
's JSONdict
and extract the timestamp:Check that the timestamps are the same:
Expected behaviour
The timestamps should be the same.
Actual behaviour
The timestamps differ by the local UTC offset (reversed):
When the
Message
is constructed, thedatetime
object it gets represents UTC time, but when it gets re-converted to a timestamp, that same object is assumed to be in local time, which in my case is7200
seconds ahead of UTC, so the resulting timestamp is7200
seconds behind the original.Configuration
Operating System: Windows
Version of Python, python-telegram-bot & dependencies:
$ python -m telegram
The text was updated successfully, but these errors were encountered: