This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: datetime utcfromtimestamp ignores astimezone
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Piotr Kamoda, SilentGhost
Priority: normal Keywords:

Created on 2019-05-13 09:29 by Piotr Kamoda, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (6)
msg342297 - (view) Author: Piotr Kamoda (Piotr Kamoda) Date: 2019-05-13 09:29
See below code:
>>> datetime.utcfromtimestamp(1557395250).astimezone(get_localzone()).strftime('%Y-%m-%d %H:%M:%S %z %Z')
'2019-05-09 09:47:30 +0200 CEST'
>>> datetime.fromtimestamp(1557395250).astimezone(get_localzone()).strftime('%Y-%m-%d %H:%M:%S %z %Z')
'2019-05-09 11:47:30 +0200 CEST'

As you can see, utcfromtimestamp refuses to be 'timezoned', second one is correct.
msg342299 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2019-05-13 09:32
The utcfromtimestamp returns a naïve object that is assumed to be in the UTC timezone, you're then effectively turning it into a aware object in CEST timezone. I'm not sure what you think is wrong with utcfromtimestamp here, but it behaves according to documentation.
msg342300 - (view) Author: Piotr Kamoda (Piotr Kamoda) Date: 2019-05-13 09:44
Docs state that fromtimestamp returns a naive datetime object (https://docs.python.org/3.7/library/datetime.html#datetime.datetime.fromtimestamp) and not utcfromtimestamp. Perhaps it needs fixing.

Additionally, astimezone fails silently, I even tried
>>> datetime.utcfromtimestamp(1557395250).astimezone(pytz.utc).astimezone(get_localzone()).strftime('%Y-%m-%d %H:%M:%S %z %Z')
'2019-05-09 09:47:30 +0200 CEST'
Which looks weird, but why it ignores that function silently is also weird.
msg342301 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2019-05-13 09:52
In the same page about utcfromtimestamp https://docs.python.org/3.7/library/datetime.html#datetime.datetime.utcfromtimestamp it says:

> with tzinfo None

Also below, "To get an aware datetime object". All this means or implies naïve object.

I've no idea what you mean by "fails silently". In what way does astimezone fail silently. You have your naïve object, then you convert it aware object, then to a different timezone. What is the problem here?
msg342303 - (view) Author: Piotr Kamoda (Piotr Kamoda) Date: 2019-05-13 10:07
Ok, now I see that naive object assumes my timezone in some cases. That's still mind-boggling that utcfromtimestamp returns an object that shows utc hour but when astimezone is applied it reverts without converting the hour to local timezone.

See below as explanation:
>>> datetime.utcfromtimestamp(1557395250).astimezone(pytz.utc).strftime('%Y-%m-%d %H:%M:%S %z %Z')
'2019-05-09 07:47:30 +0000 UTC'
>>> datetime.utcfromtimestamp(1557395250).astimezone(get_localzone()).strftime('%Y-%m-%d %H:%M:%S %z %Z')
'2019-05-09 09:47:30 +0200 CEST'
msg342305 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2019-05-13 10:21
Naïve object does not assume anything, naïve object *lacks* timezone information. It cannot convert anything. It is a mistake to set a wrong timezone to a naïve object, a mistake that you're making.

Piotr, this is a bug tracker for development of CPython, let's not turn it into support forum, there are many of those on the internet. I will not respond any further and I hope you're satisfied that this is not an issue in datetime module as distributed with standard library.
History
Date User Action Args
2022-04-11 14:59:15adminsetgithub: 81080
2019-05-13 10:21:22SilentGhostsetmessages: + msg342305
2019-05-13 10:07:26Piotr Kamodasetmessages: + msg342303
2019-05-13 09:52:34SilentGhostsetmessages: + msg342301
2019-05-13 09:44:46Piotr Kamodasetmessages: + msg342300
2019-05-13 09:35:18SilentGhostsetcomponents: + Library (Lib)
2019-05-13 09:32:50SilentGhostsetstatus: open -> closed

type: behavior

nosy: + SilentGhost
messages: + msg342299
resolution: not a bug
stage: resolved
2019-05-13 09:29:19Piotr Kamodacreate