2015-02-27 3 views
0

У меня есть строка "20150219-0700", чтобы представить время. Я хочу получить временную метку этого значения в миллисекундах. Что я сделал:Значение временной отметки за 4 часа

extracted_ts = "20150219-0700" 

int_ts = int(datetime.datetime.strptime(extracted_ts, "%Y%m%d-%H%M").timestamp()) * 1000 

Однако выход 1424358000000. Он находится за 4 часа

Правильный выход должен быть 1424329200000

+1

Добро пожаловать на разницу между местным и универсальным временем. –

ответ

2

Метод timestamp регулирует время от текущего часового пояса в UTC. Если это не то, что вы хотите, вы можете преобразовать его вручную, используя формулу из timestamp documentation:

int_ts = int((datetime.datetime.strptime(extracted_ts, "%Y%m%d-%H%M") - datetime.datetime(1970,1,1)).total_seconds()) * 1000 
+0

не удается, если вход не находится в UTC, и в задаче недостаточно информации для определения часового пояса с уверенностью. Кроме того, 'int (diff.total_seconds()) * 1000' может потерять точность в общем случае. См. [Как оба вопроса обрабатываются в моем ответе] (http://stackoverflow.com/a/28779031/4279) – jfs

2

Поскольку вы используете python3, как насчет:

from datetime import datetime, timezone 
s = "20150219-0700" 
d = datetime.strptime(s, "%Y%m%d-%H%M").replace(tzinfo=timezone.utc) 
print(int(d.timestamp() * 1000)) 

Выход:

1424329200000 
+0

он терпит неудачу, если вход не находится в UTC, и в вопросе недостаточно информации для определения часового пояса с определенность. Кроме того, 'int (d.timestamp() * 1000) может потерять точность в общем случае. См. [Как оба вопроса обрабатываются в моем ответе] (http://stackoverflow.com/a/28779031/4279) – jfs

+0

@ JFSebastian они были довольно ясны в отношении того, что их ожидаемый результат был, и уже имел метод, который учитывал время зона. –

+0

@MarkRansom: есть другие часовые пояса, кроме локальных и UTC (особенно в области приложения, где используется Python, [пример] (http://stackoverflow.com/q/28775650/4279)). Прочтите [мой ответ] (http://stackoverflow.com/a/28779031/4279). Как вы думаете, ожидаемый результат для «20150619-0700»? Зачем? – jfs

2

Вы получаете правильную метку времени, если вы интерпретируете строку времени ввода как время в UTC.

Примечание: этот вывод основан только на ("20150219-0700", 1424329200000) паре, которая согласуется с UTC, но этого недостаточно в общем случае, например, вы получаете точный результат, если строка времени ввода находится в еврозоне/лондонском часовом поясе ( GMT+0000), что имеет

Вы должны знать, входной часовой пояс для преобразования времени в POSIX временной метки:

#!/usr/bin/env python3 
from datetime import datetime, timedelta 
import pytz # $ pip install pytz 

Epoch = datetime(1970, 1, 1, tzinfo=pytz.utc) 
tz = pytz.timezone('Europe/London') # input timezone 

naive_dt = datetime.strptime("20150219-0700", "%Y%m%d-%H%M") 
dt = tz.localize(naive_dt, is_dst=None) # make it aware 
timestamp_millis = (dt - Epoch) // timedelta(milliseconds=1) 
# -> 1424329200000 

Примечание: последнее выражение может дать более точный результат, чем int(dt.timestamp()*1000) или int(diff.total_seconds()*1000) формул. См. Обсуждение в проблеме Python: timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas, например, «n/10**6 и n/1e6 - это не то же самое».

Если вы уверены, что входной часовой пояс UTC, то вы можете оставить вход в наивных объекты даты и времени:

#!/usr/bin/env python3 
from datetime import datetime 

Epoch = datetime(1970, 1, 1) 
utc_dt = datetime.strptime("20150219-0700", "%Y%m%d-%H%M") 
timestamp_millis = (utc_dt - Epoch) // timedelta(milliseconds=1) 
+0

Я думаю, что можно с уверенностью предположить, что OP хотел отметки времени UTC – JuniorCompressor

+0

@JuniorCompressor: это так. Существует разница между «секундами с эпохи» (что возвращает 'time.time()' 'и« секунды с момента Epoch »(время POSIX), если' time.time() 'использует' 'right '' timezones, но это редко , Люди, которые говорят UTC timestamp, фактически означают время POSIX. – jfs

+0

@JuniorCompressor: Или вы говорите о * input *? Если это так, как я сказал, недостаточно доказательств для * «безопасно предположить» *, что вход в UTC, как я показал выше, вход может быть в Европе и Лондоне. – jfs

Смежные вопросы