it can mean Indian Standard Time, Iran Standard Time, Irish Standard Time or Israel Standard Time

知ってる人にとっては「あぁ、あれか」なのかも。

実は今はじめて気付いた。time zone abbreviations はユニークじゃないのな。冷静に考えりゃ当たり前だ。「ST」は全部共通なんだから。

PST が「Pacific Standard Time (North America)」(UTC−08)と「Philippine Standard Time」(UTC+08)という、正負が違うだけという重複も凄いと思うが、Parsing date/time string with timezone abbreviated name in Python? で言及されてる IST の重複っぷりがステキ過ぎてぷちころすけやりたい。

日付時刻まわりの処理が悩ましいのは歴史的にずっとのことで今更何一つ驚くようなものはないけれど、そして ISO8601 をもってしても未だに格段収束するでもなく、てのも別に驚きはしない。つーか RFC822 なんか捨ててしまって 8601 に乗り換えられないもんだろうか。

てのは「メールヘッダ」の話ね(SMTP)。これ、RFC822、RFC2822 なわけだ。日付時刻の形式はこんななの：

1 Mon, 02 Nov 2015 21:00:44 -0800 (PST)

この例のように time zone abbreviations がオプショナルな様式な場合は困らないの。けどね、

1 Mon, 02 Nov 2015 21:00:44 PST

これだとアウト。-0800なのか+0800なのか区別出来ない。

これ、じっくり 2822 を読んでみたら、「4.3. Obsolete Date and Time」として違反ではないのね。(これを使ってメッセージ交換はしてはならないが、解析処理はこれを不当としてはならない、というヤツ。)

Python の email.utils モジュールの parsedate_tz では：

1 >>> from email.utils import parsedate, parsedate_tz
2 >>> parsedate_tz("Mon, 02 Nov 2015 21:00:44 +0000")  # 期待通り振舞う
3 (2015, 11, 2, 21, 0, 44, 0, 1, -1, 0)
4 >>> parsedate_tz("Mon, 02 Nov 2015 21:00:44 -0800")  # 期待通り振舞う
5 (2015, 11, 2, 21, 0, 44, 0, 1, -1, -28800)
6 >>> parsedate_tz("Mon, 02 Nov 2015 21:00:44 PST")  # 何許容してんだよ(でも RFC2822 の通り)
7 (2015, 11, 2, 21, 0, 44, 0, 1, -1, -28800)
8 >>> parsedate_tz("Mon, 02 Nov 2015 21:00:44 JST")  # ほらみたことか(でも RFC2822 の通り)
9 (2015, 11, 2, 21, 0, 44, 0, 1, -1, None)