tz = pytz.timezone('America/Los_Angeles')
t1 = pd.Timestamp(datetime.datetime(2019, 2, 6, 17, 0, 0, tzinfo=tz))
t1
Выход:
Timestamp('2019-02-06 17:00:00-0753', tz='America/Los_Angeles')
Почему -0753?
Обновлять: После некоторых исследований этот способ, кажется, работает: Я мог бы сделать это не так, см. Ниже
tz = pytz.timezone('America/Los_Angeles')
t1 = datetime.datetime(2019, 2, 6, 17, 0, 0)
t1 = tz.localize(t1)
t1 = pd.Timestamp(t1)
t1
Выход:
Timestamp('2019-02-06 17:00:00-0800', tz='America/Los_Angeles')
Каким должен быть объект tzinfo
при передаче в datetime.datetime
?
@OlvinRoght, я чувствую, что это, вероятно, связано с проблемой экономии времени, но не знаю, как с этим справиться.
Вы используете pytz для переключения между часовыми поясами?
Теперь я хочу понять, как обрабатывается dst, когда, например. преобразование времени UTC в Америка/Лос-Анджелес
Переход на летнее время не имеет смысла. С dst должно быть -0800 а не 0753
Я не знаю почему, но это странное смещение часового пояса исходит от pytz. См. код ниже:
>>>print(datetime(2019, 5, 10, tzinfo=pytz.timezone('America/Los_Angeles')))
2019-05-10 00:00:00-07:53
>>>print(pytz.timezone('America/Los_Angeles').localize(datetime(2019, 5, 10)))
2019-05-10 00:00:00-07:00
Итак, если вы пытаетесь создать дату и время и предоставить tzinfo
, это создаст это смещение.
Обновление
Я проверил pytz документы и нашел следующее:
Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones.
...
It is safe for timezones without daylight saving transitions though, such as UTC.
Ладно, говорят, но не указывают причину. Попробуем найти. В источниках pytz я нашел версию База данных IANA, которую они используют:
OLSON_VERSION = '2019a'
После скачивания и распаковки этой базы данных в файле "Northamerica" я обнаружил следующее:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02
-8:00 US P%sT 1946
-8:00 CA P%sT 1967
-8:00 US P%sT
-7:52:58
довольно близко к -07:53
у нас есть.
Заключение: Где-то в pytz есть база данных, содержащая все известные смещения часовых поясов. Когда мы передаем tzinfo в конструктор datetime, он получает первый известный часовой пояс и использует его, когда метод локализации, который вызывает заменять() и передает tzinfo, каким-то образом получает правильное смещение часового пояса.
Чтобы проверить это, я нашел в том же файле другой часовой пояс:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Toronto -5:17:32 - LMT 1895
-5:00 Canada E%sT 1919
-5:00 Toronto E%sT 1942 Feb 9 2:00s
-5:00 Canada E%sT 1946
-5:00 Toronto E%sT 1974
-5:00 Canada E%sT
И затем я запустил следующий код:
>>>print(datetime(2019, 5, 10, tzinfo=pytz.timezone('America/Toronto')))
2019-05-10 00:00:00-05:18
Как видите, результат тот же. Он использовал -5:17:32
, который является первым смещением в списке.
-0753
— смещение часового пояса. Но для Лос-Анджелеса это должно быть-0700
, так что .. Я понятия не имею, почему такой номер предоставлен :D