discrepancy with datetime with timezone

[XJia]

Can anyone please help explain about the following. why don't I get even numbers for the hours?

I'm running Python 3.10. The following is from ptpython session:
`
>>> import pytz
... from datetime import datetime
...
... # Define time zones for Eastern Time and Pacific Time
... eastern_timezone = pytz.timezone("US/Eastern")
... pacific_timezone = pytz.timezone("US/Pacific")
...
... # Create datetime objects with accurate timezone offsets
... dt1 = datetime(2023, 1, 1, 11, 0, 0, 0, tzinfo=eastern_timezone) # Eastern Time
... dt2 = datetime(2023, 1, 1, 8, 0, 0, 0, tzinfo=pacific_timezone) # Pacific Time
...
... print(dt1)
... print(dt2)
2023-01-01 11:00:00-04:56
2023-01-01 08:00:00-07:53
>>> dt1 - dt2
datetime.timedelta(seconds=180)
`

*********
Update: The issue is pytz. It should not be used for timezone after Python 3.9. https://pypi.org/project/pytz-deprecation-shim/

pytz has served the Python community well for many years, but it is no longer the best option for providing time zones. pytz has a non-standard interface that is very easy to misuse; this interface was necessary when pytz was created, because datetime had no way to represent ambiguous datetimes, but this was solved in in Python 3.6, which added a fold attribute to datetimes in PEP 495. With the addition of the zoneinfo module in Python 3.9 (PEP 615), there has never been a better time to migrate away from pytz.

[Pedroski55]

If you know the time difference, you could just use timedelta.

from datetime import datetime, timedelta

now = datetime.now()
coming = now + timedelta(days=222)
print(coming.strftime('%A %d-%m-%Y, %H:%M:%S'))
othertz = now - timedelta(hours=8)
print(othertz.strftime('%A %d-%m-%Y, %H:%M:%S'))

[snippsat]

zoneinfo that takes over for pytz.
I would advice to using Pendulum when working with timezones,or in general for better date/time stuff.

Pendulum is a Python package to ease datetimes manipulation.
It provides classes that are drop-in replacements for the native ones (they inherit from them).
Special care has been taken to ensure timezones are handled correctly,
and are based on the underlying tzinfo implementation.
For example, all comparisons are done in UTC or in the timezone of the datetime being used.

Example in your case difference would 0,as Eastern Time is 3 hours ahead of Pacific Time,so i add some hours.

 import pendulum

dt1 = pendulum.datetime(2023, 1, 1, 14, 6, 0, 0, tz="US/Eastern") # Eastern Time
dt2 = pendulum.datetime(2023, 1, 1, 8, 0, 0, 0, tz="US/Pacific")  # Pacific Time
period = dt1 - dt2

>>> period.hours
3
>>> period.minutes
6
>>> period.seconds
11160

# Look at formatting
>>> dt1
DateTime(2023, 1, 1, 14, 6, 0, tzinfo=Timezone('US/Eastern'))
>>> print(dt1)
2023-01-01T14:06:00-05:00
>>> dt1.to_datetime_string()
'2023-01-01 14:06:00'
>>> dt1.to_rfc850_string()
'Sunday, 01-Jan-23 14:06:00 EST'
>>> dt2.to_rfc850_string()
'Sunday, 01-Jan-23 08:00:00 PST'
>>> dt1.to_rfc1036_string()
'Sun, 01 Jan 23 14:06:00 -0500'

[deanhystad]

The warning has nothing to do with the two time zones being 3 hours and 180 seconds apart. That 180 seconds is being accurately reported by pytz which uses the Olson timezone database. The Olson timezone database is quite literal about what is meant by GMT, and it is using GMT offset to convert your eastern and pacific times to GMT. When you subtract your two times, it is subtracting the GMT times.

https://en.wikipedia.org/wiki/Tz_database

An example from the database

# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/New_York -4:56:02 - LMT 1883 November 18, 12:03:58
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT