We Keep Coding

python datetime timestamp conversion inconsistency

When I tried to convert a datetime object into timestamp and convert it back the result if off by 53 minutes.
timestamp = datetime.datetime(2022, 5, 3, 18, 0, 0, 0, tzinfo=pytz.timezone('US/Pacific')).timestamp()
# timetamp = 1651629180
datetime.datetime.fromtimestamp(timestamp, tz=pytz.timezone('US/Pacific'))
# formmated_timestamp = datetime.datetime(2022, 5, 3, 18, 53, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>)
somehow the result is off by 53 minutes. This is true for all other values as well
The issue seems to be at the .timestamp() part

From the pytz docs:
This library only supports two ways of building a localized time. The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information):
>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
>>> print(loc_dt.strftime(fmt))
2002-10-27 06:00:00 EST-0500
The second way of building a localized time is by converting an existing localized time using the standard astimezone() method:
>>> ams_dt = loc_dt.astimezone(amsterdam)
>>> ams_dt.strftime(fmt)
'2002-10-27 12:00:00 CET+0100'
Unfortunately using the tzinfo argument of the standard datetime constructors ''does not work'' with pytz for many timezones.
>>> datetime(2002, 10, 27, 12, 0, 0, tzinfo=amsterdam).strftime(fmt)
'2002-10-27 12:00:00 LMT+0020'

Unexpected UTC offsets of fractions of an hour using PYTZ with common timezones

I am having trouble understanding the effect of timezone offsets using pytz.
I start with a time in UTC, like this:
>>> utc = datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=pytz.timezone("UTC"))
Now I take the same wall clock time in EST, which is 5 standard meridians to the west and should differ (I believe) by 5 hours.
>>> est = datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=pytz.timezone("US/Eastern"))
>>> est-utc
datetime.timedelta(seconds=17760)
>>> 17760/3600
4.933333333333334
That difference is not the 5 hours I expect, but 4h56m, short by 4 minutes
Continuing to the west I try to arrive at times with one hour successively earlier:
>>> cst = datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=pytz.timezone("US/Central"))
>>> cst-utc
datetime.timedelta(seconds=21060)
>>> 21060/3600
5.85
That difference is not the expected 6 hours, but 5h51, short by 9 minutes.
>>> mst = datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=pytz.timezone("US/Mountain"))
>>> mst-utc
datetime.timedelta(seconds=25200)
>>> 25200/3600
7.0
This yields the expected 7-hour difference.
>>> pst = datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=pytz.timezone("US/Pacific"))
>>> pst-utc
datetime.timedelta(seconds=28380)
>>> 28380/3600
7.883333333333334
Now the difference is not the expected 8 hours but 7h53, short by 7 minutes.
And if I display the times, this is what I get:
>>> est
datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=<DstTzInfo 'US/Eastern' LMT-1 day, 19:04:00 STD>)
>>> cst
datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=<DstTzInfo 'US/Central' LMT-1 day, 18:09:00 STD>)
>>> mst
datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=<DstTzInfo 'US/Mountain' LMT-1 day, 17:00:00 STD>)
>>> pst
datetime.datetime(2021, 3, 5, 7, 59, 58, tzinfo=<DstTzInfo 'US/Pacific' LMT-1 day, 16:07:00 STD>)
So datetime is fully aware that the UTC offsets of these times vary from the expected even number of hours by respectively 4, 9, 0 and 7 minutes.
Clearly my expectations of how these timezone offsets should work is not correct.
I tried again with simpler timezone names: pytz recognizes EST and CST, and yields the expected whole-hour offsets for them, but rejects MST and PST.
Now, I obtained these results on Windows 10, and I can already hear an answer along the lines of "Ah, well, Windows, everybody knows that timezones on Windows are bizarre" (which is true), but they are not that bizarre, and besides, I get results identical to the ones shown above from Python 3.8 on Linux.
What am I missing here?

It appears that the simplest solution is not to try and understand what pytz.tzinfo is doing, but instead move to zoneinfo.ZoneInfo that was added to the standard library in Python 3.9.

Datetime print time without offset

I am currently trying to convert times from UTC and the problem that i am having is that the offsets seem to be backwards. As you can see when i convert the UTC to EST, it shows an offset of -4:56 yet when i print the time, it seems to add 4:56 as opposed to the way it should be. I would really like to be able to convert a UTC time to any other timezone and have it display the local time there without the offset so the UTC here would be converted to something along the lines of 2019-03-06 9:12 EST.
>>> example.created
datetime.datetime(2019, 3, 6, 14, 8, 49, 841881, tzinfo=<UTC>)
>>> original_utc = example.created
>>> original_utc
datetime.datetime(2019, 3, 6, 14, 8, 49, 841881, tzinfo=<UTC>)
>>> conv_est = original_utc.replace(tzinfo=pytz.timezone('US/Eastern'))
>>> conv_est
datetime.datetime(2019, 3, 6, 14, 8, 49, 841881, tzinfo=<DstTzInfo 'US/Eastern' LMT-1 day, 19:04:00 STD>)
>>> print(conv_est)
2019-03-06 14:08:49.841881-04:56
>>> print(conv_est.astimezone())
2019-03-06 19:04:49.841881+00:00

I suspect that you misunderstood the method .astimezone().
Your original datetime is in UTC
>>> example.created
datetime.datetime(2019, 3, 6, 14, 8, 49, 841881, tzinfo=<UTC>)
Then you changed the timezone info for the variable conv_est, and indeed it works as designed:
>>> conv_est = original_utc.replace(tzinfo=pytz.timezone('US/Eastern'))
>>> conv_est
datetime.datetime(2019, 3, 6, 14, 8, 49, 841881, tzinfo=<DstTzInfo 'US/Eastern' LMT-1 day, 19:04:00 STD>)
If you print this variable, it shows the correct info
>>> print(conv_est)
2019-03-06 14:08:49.841881-04:56
But when you call .astimezone() without any argument, then the return value is a datetime object in UTC zone; that means the method is also working as designed, returning the same point in time but expressed as localtime in UTC (It will be 7PM/19hs in UTC when it is 2PM/14hs in US/Eastern).
>>> print(conv_est.astimezone())
2019-03-06 19:04:49.841881+00:00
You can test that yourself by calculating the difference (which will be 0):
>>> conv_est == conv_est.astimezone()
True
>>> conv_est - conv_est.astimezone()
datetime.timedelta(0)

Time localized wrongly in Python

Using python Im trying to localize a datetime value to timezone "America/Chicago" which is -06:00 currently.
I get the timezone the following way:
>>> import pytz
>>> tz = pytz.timezone("America/Chicago")
<DstTzInfo 'America/Chicago' CST-1 day, 18:00:00 STD>
when I localize a date:
>>> my_date = tz.localize(datetime.now())
datetime.datetime(2016, 9, 24, 17, 4, 43, 439824, tzinfo=<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST>)
Notice it is the wrong timezone after localize:
<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST>
And later when i ask for the offset, you can see it is confirmed it has the wrong offset:
>>> my_date.strftime("%z")
'-0500'
Exactly the same happend if I use astimezone instead:
>>>my_date
datetime.datetime(2016, 9, 24, 22, 15, 1, 620364, tzinfo=<UTC>)
>>>my_date.astimezone(tz)
datetime.datetime(2016, 9, 24, 17, 15, 1, 620364, tzinfo=<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST>)

Btw Chicago is observing DST now. So -05.00 is the right offset. Pytz timezone by default has the standard time, but when localized can account for day light saving based on the date(as in your case).

timezone conversion in Python

I'm probably missing something about timezones:
>>> import datetime, pytz
>>> date = datetime.datetime(2013,9,3,16,0, tzinfo=pytz.timezone("Europe/Paris"))
>>> date.astimezone(pytz.UTC)
datetime.datetime(2013, 9, 3, 15, 51, tzinfo=<UTC>)
I was expecting
datetime.datetime(2013, 9, 3, 15, 00, tzinfo=<UTC>)
Can anyone explain me where these 51 minutes come from?
Thanks,
Jean-Philippe

The UTC offset gives (date.tzinfo.utcoffset(date)):
datetime.timedelta(0, 540)
This is 540 seconds or 9 minutes.
In France the switch to UTC was made on March 11, 1911 and the clocks were turned back 9 minutes and 21 seconds (source 1, source 2):
Until 1911, Paris was 9 minutes and 21 seconds off UTC.
You can also see it here (Paris time in 1911) where the time goes from March 11, 12:01:00 AM to March 10, 11:51:39 PM.

Read the note at the very begining of pytz documentation ; use .localize() method to create timezone-aware datetime object:
import datetime
import pytz
naive_dt = datetime.datetime(2013,9,3,16,0)
dt = pytz.timezone("Europe/Paris").localize(naive_dt, is_dst=None)
to_s = lambda d: d.strftime('%Y-%m-%d %H:%M:%S %Z%z')
print(to_s(dt))
print(to_s(dt.astimezone(pytz.utc)))
Output
2013-09-03 16:00:00 CEST+0200
2013-09-03 14:00:00 UTC+0000
I don't know why you are expecting 15:00 UTC here.

Thanks Simeon for your answer. It made me realize how shallow is my understanding of all of this. The following experimentations lost me a little more...
>>> import datetime, pytz
>>> date_paris = datetime.datetime(2013,9,3,16,0, tzinfo=pytz.timezone("Europe/Paris"))
>>> date_utc = datetime.datetime(2013,9,3,16,0, tzinfo=pytz.utc)
>>> date_paris.astimezone(pytz.utc)
datetime.datetime(2013, 9, 3, 15, 51, tzinfo=<UTC>)
>>> date_utc.astimezone(pytz.timezone("Europe/Paris"))
datetime.datetime(2013, 9, 3, 18, 0, tzinfo=<DstTzInfo 'Europe/Paris' CEST+2:00:00 DST>)
Why this 9 minutes offset shows up when converting in one direction but not the other? The following piece of code concentrate all disappointment:
>>> date_paris
datetime.datetime(2013, 9, 3, 16, 0, tzinfo=<DstTzInfo 'Europe/Paris' PMT+0:09:00 STD>)
>>> date_paris.astimezone(pytz.utc).astimezone(pytz.timezone("Europe/Paris"))
datetime.datetime(2013, 9, 3, 17, 51, tzinfo=<DstTzInfo 'Europe/Paris' CEST+2:00:00 DST>)