Я анализирую и манипулирую некоторыми датами и временем, которые по причинам совместимости с другими системами также необходимо сохранять как метки времени UNIX (эпоха). При этом я наблюдаю странное поведение в pandas Timestamp.tz_convert (), а затем в его поведении Timestamp.strftime () при приведении к эпохе, что заставляет меня сомневаться в моем понимании того, что должно происходить.
Времена, с которыми я работаю, находятся в часовом поясе США / Восточной Америки, но, конечно, время эпохи - UTC, поэтому мой подход заключался в приведении к UTC, поскольку большинство преобразований в / из отметок времени UNIX Предположим, что tz-naive DateTime находится в UTC. Давайте оставим в стороне, является ли это преобразование абсолютно необходимым для получения правильных временных отметок; вот что я вижу, это проблематично:
1. Использование Timestamp.tz_convert () для изменения представления временной метки временной метки (то есть универсальной точки времени) также изменяет метку времени UNIX при преобразовании с использованием Timestamp.strftime ().
2. Различия в этих временных метках даже не соответствуют разницам между часовым поясом США и Гринвичом.
Вот несколько основных интерактивных режимов Python для иллюстрации:
>>> import pytz
>>> from pytz import timezone
>>> import pandas as pd
>>> dtest = pd.to_datetime("Sunday, July 28, 2018 10:00 AM", infer_datetime_format=True).replace(tzinfo=timezone('America/New_York')) # okay, this should uniquely represent a point in time
>>> dtest
Timestamp('2018-07-28 10:00:00-0400', tz='America/New_York') # yup, that's the time - 10AM at GMT-0400.
>>> dtest2 = dtest.tz_convert('UTC') # convert to UTC
>>> dtest2
Timestamp('2018-07-28 14:00:00+0000', tz='UTC') # yup, same point in time, just different time zone now
>>> dtest.strftime('%s') # let's convert to unix time - this looks right
'1532786400'
>>> dtest2.strftime('%s') # should be the same, but it's not. WTF?
'1532804400'
Отметки времени выглядят так, как будто они описывают вещи одинаково: одна - 10:00 в GMT-0400, другая - 2:00 в GMT + 0000, разница, как и ожидалось, составляет 4 часа времени. Они оба, конечно, с учетом часового пояса. Но затем преобразование их в метки времени UNIX дает
(А) разные цифры, и даже хуже,
(B) числа, которые отличаются на 5 часов (18000 секунд = 5 * 60 * 60), а не на 4, поэтому я даже не могу предположить, что strftime () просто игнорирует часовой пояс.
Я использую https://www.epochconverter.com/, чтобы проверить любые временные метки, так как я проверяю это, так что это возможная точка заблуждения. Но согласно этому сайту,
1532786400 = 2018-07-28T10: 00 -0400 и
1532804400 (последний результат) = 2018-07-28T15: 00 -0400 или 19:00 по Гринвичу, разница 5 часов.
Есть много вопросов по теме разметки панд времени из отметки времени UNIX, но очень мало по вопросам, приведенным к времени эпохи. Я могу придумать 2 возможных объяснения:
(1) tz_convert () извлекает некоторую переменную среды в моей системе, которая говорит, что я GMT -0500, и использует ее в процессе преобразования, несмотря на то, что она не имеет отношения к преобразованию между отметками времени с учетом часового пояса, и при этом фактически меняется базовый момент времени, который будет представлен. Или:
(2) Ошибка Timestamp.strftime () и либо игнорирует параметр часового пояса временной метки с поддержкой tz, либо делает что-то действительно странное, когда запрашивается параметр форматирования «% s».
Весь совет с благодарностью.