これはiOS Advent Calendar 2016の12/2の記事です。 アドベントカレンダーはDate/Calendarネタを描こうと思っているので、今年はいろいろな現場で必ず目にする日付フォーマットのバグについて。 ある程度iOSをやっている方には当たり前の話なんですが、なぜかこのバグはいろんなところで見かけるんですよね……。 最近iOSをはじめた人は是非覚えておいてくださいね。
日時情報フォーマット
みなさん、APIに日付を含まれる場合、どんなフォーマットにしているでしょうか。
一般的に使われるのは、ISO8601かUnix timestamp。 ISO8601はWebの世界で標準的に使われている日時を表す文字列、Unix timestampは1970/1/1からの秒数を表す数値です。 ISO8601は文字列なので、ぱっと見て日時を識別できるのが利点であり、Unix timestampは変換時のバグが処理時間が少ないのが、利点です。
生のログを見るときにはISO8601は視認性がいいですが、その利点をうわまわるバグが発生していると思うので、私は自分でAPIの設計をするときには、必ず Unix timestamp を使うようにしています。
Webの世界でも、新しいAPIには、Unix timestampが多いようです。 （例えばTwitter APIはISO 8601形式、SlackのAPIなどはUnix timestampになっています。）
iOSでの正しい ISO 8601 Format
さて、iOSでISO8601文字列を作るときにはどうすればいいでしょうか。 ISO8601 iOS でググるといろいろ情報がでてきますが、だいたいこんな感じのものがでてくるかと思います。
let targetDate = Date() // 変換対象日時 let myISO8601Formatter = DateFormatter() myISO8601Formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZZZZZ" let result = myISO8601Formatter.string(from: targetDate) // ISO8601形式の文字列（と思われるもの）
実は、これをそのまま実装してしまうとバグになる場合が多いです。
日付情報を文字列にする場合、対象となるカレンダーとタイムゾーンを指定する必要があるんですが、上記のようになにも設定しないとシステム設定のカレンダーとタイムゾーンが使われてしまいます。
このコードを実行すると、iOSのシステム設定のカレンダーがグレゴリオ暦になっている場合には "2016-12-02T12:34:56+09:00" が表示されますが、和暦になっている場合には "0028-12-02T12:34:56+09:00" が表示されます。
（もちろん、iOSにはグレゴリオ暦、和暦以外のカレンダーも入っているので、その場合にも同じように失敗します。）
正しいISO8601変換をする場合には、DateFormatterにカレンダーを指定しなくてはいけません。
let targetDate = Date() // 変換対象日時 let myISO8601Formatter = DateFormatter() let gregorianCalendar = Calendar(identifier: Calendar.Identifier.gregorian) myISO8601Formatter.calendar = gregorianCalendar myISO8601Formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZZZZZ" let result = myISO8601Formatter.string(from: targetDate) // ISO8601形式の文字列
これで、システム設定のカレンダーがどれに設定されていても正しいISO8601文字列が取得できます。
なお、ISO8601のフォーマットには、タイムゾーンがGMT（グリニッジ標準時）の場合と、ローカルのタイムゾーンの場合とがありますが、上記ではローカルのタイムゾーンのISO8601となります。
GMTのISO8601を取得したい場合、下記のようにtimeZoneを設定しましょう。
myISO8601Formatter.timeZone = TimeZone(abbreviation: "GMT")
これで、 "2016-12-02T03:34:56Z" を取得することができます。
iOS10以上で使えるISO8601 Format
さて、iOS10になって、APIにISO8601 Formatterが追加されました。
let targetDate = Date() let formatter = ISO8601DateFormatter() let result = formatter.string(from: targetDate) // ISO8601形式の文字列
このFormatterのいいところは、CalendarやTimezoneを設定することができなくなっているため、どんな環境でも同じ動作が保証されることです。 たとえクライアントのカレンダーが和暦になっていても、正しいISO 8601 Formatを表示することができます。
動作環境をiOS10以上にすることができるのであれば、このFormatterを使うのが一番いいでしょう。
ISO8601でUnix timestampで対応できない日時とは
さて、日時フォーマットにはISO8601よりUnix Timestampの方が圧倒的におすすめなんですが、実はUnix timestampでは表示できない時があります。
それは、地球の自転から導き出された、UT（世界時）とUTC（協定世界時）の差が生じた時、いわゆるうるう秒です。
Unix timestampは原子由来のいわば計算上の時刻なので、どうしても実際の天体の動きとはずれてしまうんですね。 そのずれを補正するために、何年かに一度うるう秒というものが挿入されます。
前回のうるう秒は2015/7/1でした。 そのときには、ISO8601で表示すると、
"2015-06-30T23:59:59Z" "2015-06-30T23:59:60Z" "2015-07-01T00:00:00Z"
の順番に時計がかわっていました。
これをunix timestampでみてみましょう。
// 2015/6/30 23:59 var dateComp20150630235959 = DateComponents() dateComp20150630235959.calendar = calendar dateComp20150630235959.year = 2015 dateComp20150630235959.month = 6 dateComp20150630235959.day = 30 dateComp20150630235959.hour = 23 dateComp20150630235959.minute = 59 dateComp20150630235959.second = 59 dateComp20150630235959.date?.timeIntervalSince1970 // => 1435676399 // 2015/6/30 23:60 var dateComp20150630235960 = DateComponents() dateComp20150630235960.calendar = calendar dateComp20150630235960.year = 2015 dateComp20150630235960.month = 6 dateComp20150630235960.day = 30 dateComp20150630235960.hour = 23 dateComp20150630235960.minute = 59 dateComp20150630235960.second = 60 dateComp20150630235960.date?.timeIntervalSince1970 // => 1435676400 // 2015/7/1 00:00:00 var dateComp20150701000000 = DateComponents() dateComp20150701000000.calendar = calendar dateComp20150701000000.year = 2015 dateComp20150701000000.month = 7 dateComp20150701000000.day = 1 dateComp20150701000000.hour = 0 dateComp20150701000000.minute = 0 dateComp20150701000000.second = 0 dateComp20150701000000.date?.timeIntervalSince1970 // => 1435676400
というように、6/30 23:60と7/1 00:00が同じunix timestam値（1435676400）となってしまい、この二つの日時をわけて認識することができません。
うるう秒自体がUTC（計算された時刻）とUT（天体の時刻）の差を補完するものなので、UTCをもとに設定されているunix timestampで表現できないんですね。
つぎのうるう秒は、来年の１月、2017/1/1。 「うるう秒」挿入のお知らせ 2016/12/31 23:59:59のあとに、2016/12/31 23:59:60という、通常にはない1秒が挿入されます。
まとめ
うるう秒が発生するときには、unix timestampでは表示できませんが、個人的なおすすめは、やっぱりバグがでない unix timestampです。 どうしてもISO8601フォーマットを使う場合には、カレンダーの設定を忘れないようにしてくださいね。
