2016-09-25 49 views
4

什麼蟒蛇time和閏秒datetime模塊的回報?什麼對閏秒蟒蛇回報

我會得到,當我們在23:59:60.5如果我叫:

  • time.time()
  • datetime.datetime.utcnow()
  • datetime.datetime.now(pytz.utc)

此外,PY2任何區別.7和py3?


爲什麼它是混淆了(至少對我來說):

datetime docs我看到:

不同的是時間模塊,datetime模塊不支持閏秒。

關於time docs我發現在用strptime解析時,「閏秒」支持。但是沒有關於time.time()的評論。

我看到使用time我得到:

>>> time.mktime(time.strptime('2016-06-30T23:59:59', "%Y-%m-%dT%H:%M:%S")) 
1467327599.0 
>>> time.mktime(time.strptime('2016-06-30T23:59:60', "%Y-%m-%dT%H:%M:%S")) 
1467327600.0 
>>> time.mktime(time.strptime('2016-07-01T00:00:00', "%Y-%m-%dT%H:%M:%S")) 
1467327600.0 

而且datetime只是打擊了起來:

>>> dt.datetime.strptime('2016-06-30T23:59:60', "%Y-%m-%dT%H:%M:%S") 
Traceback (most recent call last): 
    File "<stdin>", line 1, in &lt;module> 
ValueError: second must be in 0..59 

那我會得到在確切的時間(閏秒的中間) ?

我看了一下橡膠倍,時鐘速度放緩,重複秒,及各種瘋狂的想法,但我應該期待什麼Python的?

注:如果你不知道,如果我沒有什麼好做這件事是照顧,一個閏秒將至!!!!

+0

http://stackoverflow.com/questions/21027639/python-datetime-not-accounting-for-leap-second-properly –

+1

我希望沒有發生。你的*電腦時鐘*不會兌現閏秒;它會一直持續到下一個ntp時鐘同步,之後您的計算機時鐘將再次正確。 –

+0

@PadraicCunningham:所有的日期時間帖子都是關於如何用日期時間表示閏秒,而不能。這是關於當您嘗試處理時間*時發生的確切的閏秒*會發生什麼。在當前的計算機上,這意味着'沒有',因爲計算機時鐘不會閏秒,因爲沒有提前告訴計算機時鐘來合併計時器的時間。 –

回答

3

閏秒是偶爾手動調度。目前,電腦時鐘無法兌現閏秒;沒有標準可以先告訴他們插入一個。相反,計算機時鐘通過NTP協議週期性地重新同步時間保持,並在插入閏秒後自動調整。

接下來,計算機時鐘通常報告自以來的秒。這將會是高達datetime模塊轉換是第二計數時包括閏秒調整其會計。目前它沒有這樣做。 time.time()將只報告基於秒,因爲最劃時代的時刻計數。

所以,沒有什麼不同會發生在閏秒正式生效時,除了你的電腦時鐘會在1秒內有一段時間。

datetime的問題只覆蓋代表閏秒時間戳,它不能。無論如何,它不會被要求這樣做。

+0

這是否意味着它只是「未指定」,您的代碼需要知道NTP將如何放置在您的機器上? (假設你想繼續使用'datetime'而不是像'astropy.time'這樣的庫,謝謝@MaxNoe) –

+1

@MarioCorchero:不,我沒有說沒有指定它。你的電腦時鐘不知道閏秒,整個問題都被忽略。無論如何,你的電腦時鐘幾乎不夠準確,這就是使用NTP的原因。您的計算機始終通過該協議定期調整其時鐘。代碼中唯一需要做的事情並不是假定時間總是向前(因爲NTP調整和時區可能會導致時間倒退)。 –

+0

@MarioCorchero:對於絕大多數的程序來說,這完全是一個非問題。如果您有一個需要*絕對時間精度的用例,其中UTC時間戳非常重要,請不要使用Python,也不要依賴計算機時鐘。讓自己設置專門的時間設備。 –