我讀過一堆關於如何分析時間片的帖子。我相信我已經想出了這裏的轉換ISO8601格式的時間戳的可靠方法:Python:可靠地將8601字符串轉換爲時間戳
https://gist.github.com/3702066
最重要的部分是在astimezone(LOCALZONE)
通話時的日期被解析。這允許time.mktime()做正確的事情,似乎正確地處理夏時制。
是否有明顯的缺陷?
我讀過一堆關於如何分析時間片的帖子。我相信我已經想出了這裏的轉換ISO8601格式的時間戳的可靠方法:Python:可靠地將8601字符串轉換爲時間戳
https://gist.github.com/3702066
最重要的部分是在astimezone(LOCALZONE)
通話時的日期被解析。這允許time.mktime()做正確的事情,似乎正確地處理夏時制。
是否有明顯的缺陷?
您的代碼確實似乎甚至落在之前或剛過日光節約時間的過渡,但恐怕它仍然可能對那些極少出現故障時的位置的時區偏移實際變化時間工作。雖然我沒有一個例子來測試。因此,即使if工作(或幾乎總是工作),我認爲將UTC時間字符串以任何方式涉及或通過本地時間的方式轉換爲UTC時間戳也是瘋狂的。當地時區應該是不相關的。這是一種不需要的依賴。我不是說你是瘋了。您只是試圖使用您提供的API,而C庫的時間API則設計得非常糟糕。
幸運的是,Python提供了一個替代mktime()
的C庫應該提供的內容:calendar.timegm()
。有了這個功能,我可以重寫你的函數是這樣的:
parsed = parse_date(timestamp)
timetuple = parsed.timetuple()
return calendar.timegm(timetuple)
因爲本地時間不參與,這也消除了對pytz的依賴和嘮叨懷疑某人的本地時區的一個不起眼的神器會造成不必要的影響。
太好了,謝謝!這更好。 Gist反映您的建議更改: https://gist.github.com/3702066 – berto
不'datetime.strptime()'做到這一點? –
@PedroRomano'datetime.strptime()'產生一個'datetime'對象。這裏我們想要產生一個整數:一個'time_t',又名UNIX時間戳,也就是自1970-01-01T00:00:00Z以來的(非閏秒)秒數。 – Celada