不管是哪門語言,碰觸時間處理相關議題時,如果開發者要認真面對,往往都會感到異常複雜。
複雜來自兩個部份:時間本身就因為歷史、經濟、政治等考量而複雜,API本身的設計經常令人困惑或易於犯錯。
因此,如果想要避開後者,唯一能憑藉的,就是對於前者的認識。
舊有的time模組
對於時間處理,Python內建的標準程式庫有著兩個模組‥舊有的time模組,以及自Python 2.3開始出現的datetime模組。不少文件或書籍兩者都會介紹,並且鼓勵開發者應該使用datetime模組。
然而,實際上,並不是那麼簡單的分野。畢竟,在Python 3.x之中,time模組還是存在的,從2.3到3.x這麼長的時間裡,都未被廢棄,突顯了time模組仍有其存在的價值。
第一個價值來自於time函式。
因為,這表示了一個絕對時間:自epoch開始至今經過的秒數。雖然大多數的系統epoch,都會是1970年1月1日0時0分0秒,不過,gmtime(0)可以告訴開發者正確的答案,儘管API上有gmt字樣,實際上,表示了UTC。即便有許多開發者不知道這個事實,然而,GMT時間經常不嚴謹(且有爭議性)地被當成是UTC時間。
其他有價值的部分,則是mktime函式與struct_time。
struct_time是個橋樑,擔任著人類時間概念與機器時間概念之間的轉換工作。如果開發者手中有個包含了時間各屬性的struct_time實例,可以透過mktime轉換為epoch秒數。舉例來說,開發者若手中有個代表人類時間概念的datetime實例,可以透過timetuple方法取得struct_time,這樣就能透過mktime轉換為epoch秒數。
除此之外,對於time模組中其他API,基本上,就不鼓勵使用了。
這特別是由於time模組中許多行為,都與底層平臺相依,它們會呼叫平臺上的C程式庫,而有些函式底層可能行為不同或不支援,像是time.tzset()就只在Unix環境中,才可使用,這連帶使得strptime函式在某些情況下,無法正常運作。
使用time模組來進行時間運算,或者是時區處理,也是極度不建議的嘗試。
人類時間概念的datetime模組
人類在時間的表達上,有時只需要日期、有時只需要時間,有時會一起表達日期與時間,而且,通常不會特別聲明時區,可能只會提及年、月、年月、月日、時分秒等,簡而言之,人類在時間概念的表達,大多是籠統、片段的資訊。
Python的datetime模組,基本上可用來表達人類的時間概念。因為當中的datetime、date、time預設沒有時區資訊,單純用來表示一個日期或時間,不過這是API上的定義。若程式運行時不需處理時區轉換問題,通常所在時區就暗示著是datetime、date、time的時區,因為人們若不特別提及時區,其實就是指本地時區居多。在《Effective Python》中的〈做法45〉,就建議:「本地時鐘使用datetime而非time」。
datetime模組中,有一個不錯的設計是,datetime本身不可變動(immutable),也考量了時間運算的問題,可以使用timedelta方法指定days、seconds、microseconds、milliseconds等單位,來建立一個時間計量(duration),這支援了+、-、*、/、//、%甚至abs等運算。因此,想知道現在的時間3天又5小時28分之後,會是什麼時間,只要撰寫datetime.now() + timedelta(days = 3, hours=-5, minutes = 28)就可以了。
不過,就算使用了datetime或date的today(),或者是datetime的now()、utcnow(),謹記著它們也是不帶時區資訊的,因此嚴格來說,開發者不能說datetime.utcnow()建立的datetime實例,代表著UTC時間。例如,datetime.utcnow()若建立了datetime(2016, 5, 23, 6, 55, 30, 505080),這純粹就只是代表著:「2016年 5月23日6點55分30秒505080微秒」這個時間概念罷了。
複雜的時區處理
對於日期與時間的處理議題上,只要涉及時區,往往就會變得極端複雜,因為牽涉了地理、法律、經濟、社會,甚至政治等問題。
例如,Python的datetime實例在建立時,可以透過tzinfo參數指定時區資訊,這必須是tzinfo的實例,然而tzinfo是個抽象類別,Python官方文件中,提供了一些如何實作tzinfo子類別的範例,並且自Python 3.2起,新增了timezone類別作為tzinfo的子類別,用來提供基本的UTC偏移時區實作,其中的timezone.utc,就是指偏移為0小時的UTC時間。
因此,現在可以正式做個區分了。datetime(1975, 5, 26, 3, 20, 50, 0)只是個時間,然而t = datetime(1975, 5, 26, 3, 20, 50, 0, tzinfo = timezone.utc)就可以說它是個代表著UTC時間了,當我們想要轉換至臺灣時區的時間,由於臺灣時區基本上就是偏移8個小時,所以,我們可以撰寫為t.astimezone(timezone(offset = timedelta(hours = 8))。
不過,Python內建的timezone只單純考量了UTC偏移,不考量日光節約時間等其他因素,若需要timezone以外的其他時區定義,目前來說,得額外安裝社群貢獻的pytz模組(PEP431規範了時區支援的改進,未來可能取代pytz模組)。而pytz模組使用的是Olson時區資料庫,是許多語言及作業系統的時區資料來源。
儘管如此,時區與時區之間的轉換,依舊複雜而麻煩,因此若應用程式需要儲存時間資訊,或甚至進行時間運算,常見的建議是使用絕對的UTC時間,然後,在需要時,再透過astimezone的幫忙,轉換為當地時區。
舉個例子來說,應用程式在儲存留言時間時,可以使用UTC時間,然而網頁上要把時間呈現給使用者看時,才依照UTC時間轉為對應時區的時間。如果需要在應用程式之間交換時間資訊,以UTC時間來作為交換,也會是個好選擇。
語言間真正能過渡的部份
如果開發者從未認真處理過時間的問題,對於以上的時間概念,像是epoch、GMT、UTC等沒有明確的認知,等到開始面對time或datetime模組等,也許會感到十分困惑。
針對時區的處理,開發者更可能不解API在使用上何以如此複雜,若是如此,建議看看我先前專欄〈從JDK時間API演進,看時間處理〉,瞭解幾個需要知道的時間概念,雖然這邊是在講Python,然後過去探查JDK時間API演進而獲取的時間知識,卻是非常的受用。
舉例而言,我就曾一度被datetime的now()、utcnow(),以及today()等混淆,誤認為它們帶有時區的概念。然而,後來我開始察覺到它們傳回的物件上tzinfo是None,這令人迅速聯想到JSR310的LocalDateTime、LocalDate、LocalTime等類別,以及背後所代表的概念。於是,我將time模組與datetime模組,整個重新探查了一遍,釐清機器時間與人類時間概念間的差別,接下來,相關API如何使用,也就明朗起來了。
其實時間處理只是一個例子,在探查處理特定議題的API時,對於該門議題的背景知識,往往比找出API的參數、傳回值、相依性等外在形式來得重要。
事實上,背景知識能引導開發者思考,如何正確地使用API,避開那些令人困惑的誤區,這才是語言間真正能過渡的部份。
專欄作者
熱門新聞
2024-12-10
2024-12-10
2024-12-08
2024-12-10
2024-12-11
2024-11-29