TimeZone — その概要、Foundationクラス、タイムゾーン

FoundationにおけるTimeZoneとは？

TimeZoneはSwiftの値型で、地理的なタイムゾーンに関する情報（UTCオフセット、名前、略称、夏時間ルール）を提供します。Objective-Cでは、このクラスはNSTimeZoneと呼ばれます。両方のクラスはIANA Time Zone Database（Olsonデータベースとしても知られる）に依存しており、1970年以降のタイムゾーン変更の履歴を含んでいます。

各TimeZoneインスタンスは、タイムゾーン識別子（例：Europe/Moscow）、UTCからの現在のオフセット（秒単位）、isDaylightSavingTimeフラグ、および次の移行日を格納します。識別子が主キーです：TimeZone(identifier:)で初期化すると、システムはデバイスのタイムゾーンデータベースから対応するレコードをロードします。

IANA（2024）によると、データベースには600以上の一意のタイムゾーン識別子が含まれています。Appleは各iOSおよびmacOSリリースにこのデータベースのスナップショットを同梱しており、ネットワークリクエストを必要とせずにすべてのデバイスで一貫した計算を保証します。

iOSおよびmacOSでのTimeZoneの仕組み

アーキテクチャ FoundationのTimeZoneは2層システムで構築されています：タイムゾーン識別子（人間が読める名前）とその数値表現（UTCオフセット）です。システムはデバイス設定から現在のタイムゾーンを自動選択しますが、開発者は特定のフォーマット操作のためにこれを上書きできます。

TimeZoneはCalendarおよびDateFormatterと密接に関連しています。日付をフォーマットする際、DateFormatterはTimeZoneインスタンスのtimeZoneプロパティを使用して、絶対的な時刻（Date）を目的のタイムゾーンの文字列表現に変換します。timeZoneが設定されていない場合、デフォルトのシステムタイムゾーン — TimeZone.currentが使用されます。

TimeZoneインスタンスのタイプ

重要な注意点： TimeZone(identifier:)は不明な識別子に対してnilを返します。これはアプリクラッシュの一般的な原因です — 開発者はユーザー入力から無効な識別子を渡す際にオプショナル値の処理を忘れます。IANA識別子の場合、大文字と小文字が区別されます：Europe/Moscowは有効ですが、europe/moscowはnilを返します。

タイムゾーン識別子の形式

IANA Time Zone Databaseは「地域/都市」（大陸/都市）形式を使用します。地域は大陸の1つ（Africa、America、Asia、Atlantic、Australia、Europe、Indian、Pacific）または海洋で、都市はタイムゾーンの適用エリア内で最も人口の多い地域です。この形式は識別子の一意性と可読性を保証します。

メイン形式に加えて、TimeZoneは3つの追加識別方法をサポートしています：略称（MSK、EST、PST）、3文字のタイムゾーンコード（GMT、UTC）、および数値オフセット（+0300、-0500）。ただし、略称は曖昧です：ESTはEastern Standard Time（GMT-5）またはオーストラリアのEastern Summer Time（GMT+10）のいずれかを意味する可能性があります。AppleはIANA識別子のみを使用することを推奨しています。

import Foundation

// 既知のタイムゾーン識別子をすべて取得
let allIdentifiers: [String] = TimeZone.knownTimeZoneIdentifiers
print("総タイムゾーン数：\(allIdentifiers.count)")

// 地域でフィルタリング
let europeZones = allIdentifiers.filter { $0.hasPrefix("Europe/") }
print("ヨーロッパのタイムゾーン：\(europeZones)")

// 略称（本番環境では非推奨）
if let moscowTimeZone = TimeZone(abbreviation: "MSK") {
    print("GMTからのMSK秒：\(moscowTimeZone.secondsFromGMT())")
}

// オフセットで識別子を検索
let utcPlus3 = TimeZone(secondsFromGMT: 10800)
print("識別子：\(utcPlus3.identifier)")

略称 TimeZone.abbreviationDictionaryには既知のすべてのタイムゾーンの略称が含まれていますが、この辞書は一意性を保証しません：PSTキーはAmerica/Los_AngelesまたはPacific/Pago_Pagoのいずれかに対応する可能性があります。本番コードでは、常にIANA識別子を使用してください。

夏時間とTimeZone

TimeZoneは、夏時間（DST）が実施されているすべての地域で自動的に夏時間移行を考慮します。システムはIANA Time Zone Databaseの履歴データを使用し、各タイムゾーンの正確な移行日を含んでいます。isDaylightSavingTimeプロパティは、タイムゾーンが現在夏時間の場合にtrueを返します。

nextDaylightSavingTimeTransitionメソッドを使用すると、次の移行日を確認でき、将来のイベント計画に役立ちます。この機能は、ブラジルやモロッコなどDSTルールが頻繁に変更される地域で特に重要です — 2024年まで、ブラジルは毎年移行日を変更しており、手動計算はアプリケーションでエラーを引き起こしていました。

Apple WWDC 2023によると、Foundationの基盤となるICUライブラリ（International Components for Unicode）は、iOSのアップデートごとにDSTデータを更新します。アプリケーションはシステムアップデート後1日以上夏時間データをキャッシュすべきではありません — IANAデータベースはOSバージョンアップデートなしでもタイムゾーン調整によって変更される可能性があります。

import Foundation

// Europe/MoscowのDSTを確認
let moscow = TimeZone(identifier: "Europe/Moscow")!
let now = Date()
let isMoscowDST = moscow.isDaylightSavingTime(for: now)
print("モスクワは現在DST中：\(isMoscowDST)")

// 次のDST移行日を取得
if let nextTransition = moscow.nextDaylightSavingTimeTransition(
    after: now
) {
    let dstOffset = moscow.daylightSavingTimeOffset(
        for: nextTransition
    )
    print("次の移行：\(nextTransition)、DSTオフセット：\(dstOffset)s")
}

// DST対応の安全な変換
let newYork = TimeZone(identifier: "America/New_York")!
let offsetNY = newYork.secondsFromGMT(for: now)
print("NYの現在のオフセット：\(offsetNY / 3600)h")

重要なニュアンス： secondsFromGMT(for:)は指定された日付のDSTを考慮しますが、secondsFromGMT()は現在時刻にのみ適用されます。履歴日付をフォーマットする場合は、常にDateパラメータ付きのバージョンを使用してください：secondsFromGMT(for: someHistoricalDate)。差は1〜2時間になる可能性があり、ログや履歴データにとって重要です。

SwiftでのTimeZone：コード例

特定のタイムゾーンでの日付フォーマットは、TimeZoneを扱う際の最も一般的なタスクです。DateFormatterはtimeZoneプロパティを使用してDateを文字列に変換します。timeZoneが明示的に設定されていない場合、フォーマッタはTimeZone.current — ユーザーのデバイスに設定されたタイムゾーンを使用するため、サーバーデータに対して予期しない結果になる可能性があります。

import Foundation

// 特定のタイムゾーンで日付をフォーマット
let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd HH:mm:ss"

let tokyo = TimeZone(identifier: "Asia/Tokyo")!
formatter.timeZone = tokyo
let tokyoTime = formatter.string(from: Date())
print("東京の時刻：\(tokyoTime)")

// ユーザー選択に利用可能な識別子
let displayNames: [(String, String)] = TimeZone.knownTimeZoneIdentifiers
    .prefix(20)
    .map { ($0, TimeZone(identifier: $0)!.localizedName(
        for: .generic, locale: .current
    )) }

// 2つのタイムゾーンを比較
let london = TimeZone(identifier: "Europe/London")!
let difference = tokyo.secondsFromGMT(for: Date())
    - london.secondsFromGMT(for: Date())
print("東京-ロンドンの差：\(difference / 3600)h")

// 略称辞書を操作
let knownAbbrevs = TimeZone.abbreviationDictionary
for (abbr, ident) in knownAbbrevs.sorted(by: { $0.key < $1.key }).prefix(5) {
    print("\(abbr) -> \(ident)")
}

タイムゾーンのローカライズ名はlocalizedName(for:locale:)を介して、指定された言語で人間が読める名前を返します。たとえば、ロシアのロケールでのEurope/Moscowの場合、メソッドはロシア語名「Moskva」を返し、英語ロケールでは「Moscow Time」を返します。利用可能なスタイル：.standard（標準名）、.daylightSaving（夏時間）、.shortGeneric（短縮形）。

import Foundation

let paris = TimeZone(identifier: "Europe/Paris")!
let nameRU = paris.localizedName(
    for: .standard,
    locale: Locale(identifier: "ru_RU")
)
print("ロシア語名：\(nameRU)")

// 地域が同じ日かどうかを確認
let isSameDay = Calendar.current.isDate(
    Date(),
    equalTo: Date(),
    toGranularity: .day
)
print("タイムゾーンをまたぐ同じ日：\(isSameDay)")

タイムゾーン識別子のシリアル化は、データベースやUserDefaultsにTimeZoneを保存する最良の方法です。識別子（Europe/Moscowのような文字列）を保存し、秒単位のオフセットや略称は保存しないでください。DSTの変更に伴いオフセットが変わる可能性があり、略称は曖昧です。復元：TimeZone(identifier: savedString)。

TimeZone使用時のよくある間違い

タイムゾーン識別子の代わりに固定オフセットを使用することは最も一般的な間違いです。TimeZone(secondsFromGMT: 10800)はDSTを考慮しないため、夏季のEurope/Moscowではこの構文は1時間の誤ったオフセットを与えます。夏時間がある地域では常にIANA識別子を使用してください。

TimeZone(identifier:)初期化時のnil処理の欠如は2番目に多いエラーです。ユーザーが誤った識別子（「Europe/Moscow」の代わりに「moscow」など）を入力すると、コンストラクタはnilを返します。オプショナル値を処理しないと、アプリは実行時エラーでクラッシュします。guard letまたは既知のフォールバック付きのTimeZone(identifier:)を使用してください。

将来の日付を扱う際のDST無視。 TimeZone.secondsFromGMT(for:)は特定の日付のオフセットを取得する唯一の正しい方法です。履歴日付や将来の日付に対してパラメータなしでsecondsFromGMT()を使用すると、現在の瞬間のオフセットが返され、指定された日付の実際のオフセットと一致しない可能性があります。特にDSTを廃止または導入した地域で顕著です。

Stack Overflow（2024）によると、DateFormatterに関する質問の約15%が誤ったtimeZone設定に関連しています。典型的なシナリオ：サーバーがUTCで日付を送信し、開発者がフォーマッタのtimeZoneを設定せずにフォーマットすると、日付がデバイスのタイムゾーンで表示され、異なる地域のユーザーの間で混乱を引き起こします。ルール：サーバーデータの場合は常にフォーマッタのtimeZoneを明示的に設定してください。