29 · 시간과 달력

시간은 프로그래머의 직관이 가장 자주 배신당하는 영역이다. 하루는 24시간이 아니고, 1년은 365일이 아니며, 같은 시각이 두 번 오거나 아예 존재하지 않는 시각도 있다. 그런데 이 사실들은 대부분의 날에 아무 문제를 일으키지 않아서 코드가 몇 년씩 멀쩡히 돌다가 특정 날짜에 터진다.

P0 16장 Q4에서 벽시계와 단조 시계의 구분, 그리고 "믿을 시각은 서버, 재야 할 간격은 단조 시계"라는 원칙을 다뤘다. 이 챕터는 그 위에서 달력 계산 자체의 문제를 파고든다 — 절대 시각을 사람이 읽는 날짜로 바꾸는 순간 생기는 일들이다.

Q1. Date는 무엇을 담고 있는가?

CS 원리

시간을 다루는 시스템은 "시각(instant)"과 "그 시각의 표현(representation)"을 분리한다. 이 분리가 이 챕터 전체를 관통하는 원리다.

• 시각 — 우주에서 일어난 한 순간. 기준점으로부터 흐른 시간이라는 하나의 숫자로 표현된다. 지구 어디서 보든 같은 값이다.
• 표현 — 그 시각을 사람이 읽는 형태로 바꾼 것. "2026년 8월 15일 오후 2시 30분". 타임존과 달력이 있어야만 계산할 수 있고, 렌즈에 따라 답이 달라진다.

이 구분이 왜 중요하냐면, 많은 버그가 둘을 혼동해서 생기기 때문이다. "오늘 자정"은 시각이 아니라 표현이다 — 어느 타임존의 자정인지 정하지 않으면 의미가 없다. 반대로 "결제가 일어난 순간"은 시각이고, 이걸 지역 시간 문자열로 저장하면 정보가 손실된다.

두 번째 원리는 부동소수점 표현의 대가다. Date가 Double이라는 것은 기준점에서 멀어질수록 표현 가능한 눈금이 성겨진다는 뜻이다(30장에서 자세히 다룬다). 2026년 근처에서는 ULP(연속한 두 표현 가능 값의 간격)가 약 1.19×10⁻⁷초라 마이크로초 차이가 구분되지만, Date.distantFuture(약 4001년) 근처에서는 ULP가 약 7.6마이크로초까지 벌어진다. 그보다 촘촘한 차이는 ==로 같다고 계산된다.

iOS에서는

Date는 렌즈 없이는 아무 날짜도 아니다. 사람이 읽는 값을 얻으려면 반드시 Calendar와 TimeZone을 거쳐야 한다.

let d = Date(timeIntervalSinceReferenceDate: 787_234_200)

// 저장된 것은 이 숫자 하나뿐이다
d.timeIntervalSinceReferenceDate        // 787234200.0
d.timeIntervalSince1970                 // 1_765_454_...  (기준점만 다르다)

// 사람이 읽는 값은 렌즈를 통해서만 나온다
var seoul = Calendar(identifier: .gregorian)
seoul.timeZone = TimeZone(identifier: "Asia/Seoul")!
var la = Calendar(identifier: .gregorian)
la.timeZone = TimeZone(identifier: "America/Los_Angeles")!

seoul.dateComponents([.year, .month, .day, .hour], from: d)   // 5/9 03시
la.dateComponents([.year, .month, .day, .hour], from: d)      // 5/8 11시
//   같은 Date, 다른 날짜 — 값은 그대로다

print가 만드는 착각을 조심해야 한다.

print(d)          // 2026-05-08 18:30:00 +0000
//   Date 가 UTC 를 "갖고 있어서"가 아니라 description 이 UTC 로 찍을 뿐이다.
//   디버깅 중 이 출력을 보고 "타임존이 UTC 로 잘못 설정됐다"고 오해하기 쉽다.

distantFuture 함정도 실제로 재현된다.

let far = Date.distantFuture
let farPlus = far.addingTimeInterval(0.000_001)      // 1마이크로초 더하기

far == farPlus        // true   ← 더했는데 같다
//   4001년 근처는 ULP 가 약 7.6μs 라 1μs 차이가 표현되지 않는다

// "만료 없음"을 이렇게 흉내 내면 미세 비교가 조용히 깨진다
struct Token { let expiresAt: Date }            // ❌ distantFuture 로 무한 표현
struct Token2 { let expiresAt: Date? }          // ✅ nil 로 명시

실험 · 도구

렌즈에 따라 날짜가 갈리는 것을 직접 확인해 보자.

import Foundation

let d = Date(timeIntervalSinceReferenceDate: 787_234_200)

for tz in ["Asia/Seoul", "America/Los_Angeles", "UTC", "Pacific/Kiritimati"] {
    var cal = Calendar(identifier: .gregorian)
    cal.timeZone = TimeZone(identifier: tz)!
    let c = cal.dateComponents([.year, .month, .day, .hour, .minute], from: d)
    print(String(format: "%-22@ %d-%02d-%02d %02d:%02d",
                 tz as NSString, c.year!, c.month!, c.day!, c.hour!, c.minute!))
}
// Asia/Seoul             2026-05-09 03:30
// America/Los_Angeles    2026-05-08 11:30
// UTC                    2026-05-08 18:30
// Pacific/Kiritimati     2026-05-09 08:30    ← UTC+14, 가장 이른 타임존

정밀도 저하도 측정할 수 있다.

func ulp(of date: Date) -> Double {
    date.timeIntervalSinceReferenceDate.ulp
}

print(ulp(of: Date()))                  // 약 1.19e-07  (2026년 근처)
print(ulp(of: .distantFuture))          // 약 7.6e-06   (4001년 근처)
print(ulp(of: .distantPast))            // 과거 방향도 마찬가지로 성겨진다

// 실제로 더해도 같아지는 경계를 찾는다
var step = 1e-9
while Date.distantFuture == Date.distantFuture.addingTimeInterval(step) {
    step *= 2
}
print("distantFuture 에서 구분 가능한 최소 간격: \(step)초")

프로젝트 적용

1. 모델에는 Date만 담는다. 이미 서식된 문자열이나 "년/월/일" 정수 조합을 담으면 렌즈 정보가 사라진다.
2. "오늘"·"자정"·"이번 달"을 말할 때는 타임존을 명시한다. 이 말들은 시각이 아니라 표현이라 렌즈 없이는 정의되지 않는다.
3. "무한"을 distantFuture로 흉내 내지 않는다. Date?의 nil이나 전용 열거형으로 명시한다.
4. print(date) 출력을 타임존 설정의 근거로 삼지 않는다. 항상 UTC로 찍힌다.
5. 경과 시간 측정에는 Date를 쓰지 않는다. ContinuousClock 계열을 쓴다 — P0 16장 Q4에서 다룬 단조 시계 원칙이 그대로 적용된다.

꼬리 질문

extension Calendar {
    /// 이 달력·타임존 기준으로 주어진 시각이 속한 날의 시작(자정)
    func startOfDayInstant(for date: Date) -> Date { startOfDay(for: date) }
}

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "Asia/Seoul")!
let midnight = cal.startOfDay(for: Date())     // 절대 시각으로 반환된다

let todays = items.filter { $0.createdAt >= midnight }

// 비즈니스 로직용 — 사용자 설정과 완전히 분리한다
var biz = Calendar(identifier: .gregorian)
biz.timeZone = TimeZone(identifier: "Asia/Seoul")!    // 서비스 기준 타임존
biz.firstWeekday = 2                                   // 주 시작을 명시
biz.minimumDaysInFirstWeek = 4                         // 주차 규칙도 명시

// 표시용 — 사용자 설정을 따른다
let display = Calendar.autoupdatingCurrent

// 저장·전송 — 정수 밀리초로 고정
struct Event: Codable {
    let createdAtMs: Int64
    var createdAt: Date { Date(timeIntervalSince1970: Double(createdAtMs) / 1000) }
}

Q2. 날짜 산술은 왜 Calendar를 거쳐야 하는가?

CS 원리

달력 산술이 어려운 이유는 단위가 균일하지 않기 때문이다.

가변 단위의 산술은 대수적 성질이 깨진다. 우리가 당연히 여기는 규칙들이 성립하지 않는다.

• 결합법칙이 깨진다. (1월 31일 + 1개월) + 1개월 ≠ 1월 31일 + 2개월. 앞은 2월 28일을 거쳐 3월 28일, 뒤는 3월 31일이 된다.
• 가역성이 깨진다. +1개월 뒤 −1개월이 원래 날짜로 돌아오지 않는다.
• 덧셈 순서가 결과를 바꾼다. "+1개월 +1일"과 "+1일 +1개월"이 다를 수 있다.

그래서 직접 구현하면 안 된다. 이 조정 규칙은 문화권마다 다르고 예외가 많아서, 달력 구현체에 위임하는 것이 유일하게 안전한 방법이다.

두 번째 원리는 어느 달력을 쓸 것인가다. Calendar.current는 접근한 순간의 설정을 찍은 스냅샷이라 이후 사용자가 설정을 바꿔도 반영되지 않는다. autoupdatingCurrent는 실시간 반영되고, Calendar(identifier:)는 사용자 설정과 완전히 무관하다. 정산·마감 같은 비즈니스 로직은 반드시 고정 identifier + 고정 TimeZone을 써야 한다.

iOS에서는

먼저 어느 달력을 쓸지 정하는 것이 시작이다. 셋의 성격이 다르다.

Calendar.current              // 접근 시점의 사용자 설정 스냅샷 — 이후 변경 반영 안 됨
Calendar.autoupdatingCurrent  // 사용자 설정을 실시간 반영 — 표시용에 적합
Calendar(identifier: .gregorian)   // 사용자 설정과 완전히 무관 — 비즈니스 로직용

// 비즈니스 로직용 달력은 세 축을 모두 고정한다
var biz = Calendar(identifier: .gregorian)
biz.timeZone = TimeZone(identifier: "Asia/Seoul")!
biz.locale = Locale(identifier: "en_US_POSIX")

산술은 의도를 드러내는 API를 고른다.

let base = someDate

// "정확히 24시간 뒤" — 타임아웃·만료처럼 경과 시간이 중요한 경우
let exact = base.addingTimeInterval(24 * 60 * 60)

// "달력상 내일 같은 시각" — 알림·일정처럼 벽시계 시각이 중요한 경우
let tomorrow = biz.date(byAdding: .day, value: 1, to: base)!

// 여러 단위를 한 번에 — 순서 의존을 피한다
var comps = DateComponents(); comps.month = 1; comps.day = 15
let later = biz.date(byAdding: comps, to: base)!

월말 조정은 달력이 알아서 한다.

let jan31 = biz.date(from: DateComponents(year: 2026, month: 1, day: 31))!

biz.date(byAdding: .month, value: 1, to: jan31)!   // 2026-02-28  (조정)
biz.date(byAdding: .month, value: 2, to: jan31)!   // 2026-03-31  (조정 없음)
//   한 번에 2개월을 더한 것과, 1개월씩 두 번 더한 것이 다르다

한국 맥락에서 자주 묻는 것 하나 — Calendar.Identifier.republicOfKorea는 존재하지 않는다. 컴파일 에러가 난다. 양력은 .gregorian을 쓰고, 설날·추석 같은 음력이 필요하면 .chinese로 환산한다.

let lunar = Calendar(identifier: .chinese)
let c = lunar.dateComponents([.year, .month, .day], from: someDate)
//   실측: 2027-02-06 그레고리력이 음력 1월 1일(설날)에 해당한다

실험 · 도구

두 산술이 갈리는 날을 직접 찾아보면 감이 온다.

import Foundation

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "America/Los_Angeles")!

let fmt = DateFormatter()
fmt.locale = Locale(identifier: "en_US_POSIX")
fmt.timeZone = cal.timeZone
fmt.dateFormat = "MM-dd HH:mm zzz"

// 2026년 미국 스프링포워드는 3월 8일이다
let base = cal.date(from: DateComponents(year: 2026, month: 3, day: 7, hour: 12))!

print("출발      ", fmt.string(from: base))
print("+86400초  ", fmt.string(from: base.addingTimeInterval(86400)))
print("+1일(달력)", fmt.string(from: cal.date(byAdding: .day, value: 1, to: base)!))
// 출발       03-07 12:00 PST
// +86400초   03-08 13:00 PDT     ← 벽시계로 한 시간 밀렸다
// +1일(달력) 03-08 12:00 PDT     ← 정오가 보존됐다

1년 전체를 훑어 하루가 24시간이 아닌 날을 찾을 수도 있다.

# 특정 타임존에서 DST 전환일을 모두 나열한다
python3 - <<'PY'
from zoneinfo import ZoneInfo
from datetime import datetime, timedelta
tz = ZoneInfo("America/Los_Angeles")
d = datetime(2026, 1, 1, tzinfo=tz)
while d.year == 2026:
    nxt = d + timedelta(days=1)
    hours = (nxt.astimezone(ZoneInfo("UTC")) - d.astimezone(ZoneInfo("UTC"))).total_seconds() / 3600
    if hours != 24:
        print(f"{d.date()}  →  {hours:.0f}시간")
    d = nxt
PY
# 2026-03-08  →  23시간
# 2026-11-01  →  25시간

프로젝트 적용

1. 비즈니스 로직에는 고정 달력을 쓴다. Calendar(identifier:) + 고정 TimeZone. Calendar.current는 사용자 설정에 좌우된다.
2. "며칠 뒤"를 86400 * n으로 계산하지 않는다. 만료 시각처럼 경과 시간이 의미 있는 경우에만 초 산술을 쓴다.
3. 월 산술에서 결합법칙을 가정하지 않는다. "매월 31일 결제" 같은 규칙은 말단 처리를 명시적으로 정한다 — 말일로 당길지, 다음 달 1일로 밀지.
4. 여러 단위를 더할 때는 DateComponents로 한 번에 넘긴다. 순서 의존을 피할 수 있다.
5. DST가 있는 타임존을 테스트에 넣는다. 한국은 DST가 없어 개발 중에는 이 문제가 절대 재현되지 않는다.

꼬리 질문

// ❌ 조정된 날짜를 기준으로 다시 더하면 계속 당겨진다
//    1/31 → 2/28 → 3/28 → 4/28 …  (31일로 돌아오지 못한다)

// ✅ 원래 기준일을 유지하고 매번 원점에서 계산한다
struct Subscription {
    let anchorDay: Int          // 31 — 사용자가 고른 결제일
    let startedAt: Date

    func billingDate(monthsLater n: Int, in cal: Calendar) -> Date {
        let base = cal.date(byAdding: .month, value: n, to: startedAt)!
        var c = cal.dateComponents([.year, .month], from: base)
        let range = cal.range(of: .day, in: .month, for: base)!
        c.day = min(anchorDay, range.count)      // 그 달의 말일로 제한
        return cal.date(from: c)!
    }
}

// 한 계산 단위 안에서는 달력을 한 번만 읽어 고정한다
func summarize(_ items: [Item]) -> Summary {
    let cal = Calendar.current        // 스냅샷 — 이 함수 안에서 일관됨
    …
}

// ❌ 23:59 와 00:01 이 "0일 차이"로 나온다
let naive = Int(b.timeIntervalSince(a) / 86400)

// ✅ 날짜 경계 기준 — 두 시각을 각각 그날의 시작으로 내린 뒤 센다
func dayGap(_ a: Date, _ b: Date, _ cal: Calendar) -> Int {
    let da = cal.startOfDay(for: a)
    let db = cal.startOfDay(for: b)
    return cal.dateComponents([.day], from: da, to: db).day ?? 0
}
//   어제 23:59 → 오늘 00:01 은 1 이 나온다

date.formatted(.relative(presentation: .named))    // "어제", "3일 전"

Q3. DST 경계에서 하루는 몇 시간인가?

CS 원리

DST는 물리적 시간과 사회적 시간의 분리가 만드는 문제다. 절대 시각은 균일하게 흐르지만, 지역 시간이라는 사상(mapping)이 1년에 두 번 불연속점을 갖는다.

이 불연속이 두 종류의 이상 상태를 만든다.

• 갭(gap) — 스프링포워드. 2:00에서 3:00으로 건너뛰므로 2:00~2:59가 존재하지 않는다. 이 시각을 요구하면 시스템이 조정해야 한다.
• 중복(overlap) — 폴백. 2:00이 되면 1:00으로 돌아가므로 1:00~1:59가 두 번 나타난다. "1:30"이라는 지역 시각에 두 개의 절대 시각이 대응한다.

즉 지역 시간 → 절대 시각의 사상이 전단사(bijection)가 아니다. 어떤 값은 대응이 없고(갭), 어떤 값은 둘이다(중복). 이것이 시간 계산이 어려운 근본 이유다.

여기서 중요한 실무 원칙이 나온다 — 지역 시간 문자열은 절대 시각을 유일하게 결정하지 못한다. 그래서 시각을 저장할 때는 반드시 오프셋이나 UTC를 함께 담아야 하고, 지역 시간만 저장하면 연간 한 시간 동안의 데이터는 복원 불가능해진다.

iOS에서는

두 산술이 서로 다른 불변식을 지킨다는 것이 코드로 그대로 드러난다.

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "America/Los_Angeles")!

// 2026년 스프링포워드는 3월 8일 — 3월 7일 정오에서 출발
let base = cal.date(from: DateComponents(year: 2026, month: 3, day: 7, hour: 12))!

base.addingTimeInterval(86400)                      // 3/8 13:00 PDT — 경과 시간 보존
cal.date(byAdding: .day, value: 1, to: base)!       // 3/8 12:00 PDT — 정오 보존
//   둘 다 옳다. 무엇을 보존할지는 용도가 정한다.

존재하지 않는 시각을 요청하면 시스템이 조정한다. nil이 아니라는 점이 중요하다.

// 3/8 02:30 은 존재하지 않는다
let ghost = cal.date(from: DateComponents(year: 2026, month: 3, day: 8, hour: 2, minute: 30))
//   nil 이 아니라 기본 matchingPolicy 에 따라 다음 유효 시각으로 밀린다 (03:30)
//   "nil 이 오겠지"라고 가정한 코드는 여기서 조용히 어긋난다

타임존의 오프셋 변화를 직접 조회할 수도 있다.

let tz = TimeZone(identifier: "America/Los_Angeles")!

tz.isDaylightSavingTime(for: base)          // false (PST)
tz.secondsFromGMT(for: base)                // -28800
tz.nextDaylightSavingTimeTransition(after: base)   // 다음 전환 시각
tz.daylightSavingTimeOffset(for: base)      // 0 또는 3600

실험 · 도구

DST가 없는 한국에서 개발하면 이 문제가 절대 재현되지 않는다. 그래서 강제로 흉내 내야 한다.

// 코드에서 타임존을 명시하면 기기 설정과 무관하게 재현할 수 있다 — 테스트에 적합
func hoursInDay(_ y: Int, _ m: Int, _ d: Int, tz: String) -> Double {
    var cal = Calendar(identifier: .gregorian)
    cal.timeZone = TimeZone(identifier: tz)!
    let start = cal.date(from: DateComponents(year: y, month: m, day: d))!
    let next  = cal.date(byAdding: .day, value: 1, to: start)!
    return next.timeIntervalSince(start) / 3600
}

hoursInDay(2026, 3, 8,  tz: "America/Los_Angeles")   // 23.0
hoursInDay(2026, 11, 1, tz: "America/Los_Angeles")   // 25.0
hoursInDay(2026, 3, 8,  tz: "Asia/Seoul")            // 24.0  ← 한국은 DST 없음

시뮬레이터의 타임존을 통째로 바꿔 UI까지 확인할 수도 있다.

# 시뮬레이터 타임존 변경
xcrun simctl spawn booted defaults write .GlobalPreferences AppleTimeZone \
    -string "America/Los_Angeles"

# 기기 시각을 전환 직전으로 옮겨 실제 전환을 겪게 한다
#   설정 › 일반 › 날짜 및 시간에서 자동 설정을 끄고 수동으로 맞춘다
#   (시뮬레이터는 호스트 시각을 따르므로 macOS 쪽에서 바꿔야 하는 경우가 많다)

# 타임존 데이터베이스가 아는 전환 시각을 직접 확인
python3 -c "
from zoneinfo import ZoneInfo
from datetime import datetime
tz = ZoneInfo('America/Los_Angeles')
for m, d in [(3,8),(11,1)]:
    for h in [1,2,3]:
        t = datetime(2026,m,d,h,30,tzinfo=tz)
        print(f'{m}/{d} {h}:30 → utcoffset={t.utcoffset()}  dst={t.dst()}')
"

프로젝트 적용

1. 시각 저장에는 반드시 UTC나 오프셋을 포함한다. 지역 시간 문자열만 저장하면 연간 한 시간 분량이 복원 불가능해진다.
2. 반복 일정은 지역 시간 규칙으로 저장한다. "매일 오전 9시"를 절대 시각의 반복으로 저장하면 DST 후 8시나 10시에 울린다.
3. "하루 전체"를 다룰 때 startOfDay와 date(byAdding:)을 쓴다. 자정에 86400을 더하는 방식은 전환일에 틀린다.
4. DST가 있는 타임존을 테스트 매트릭스에 고정한다. America/Los_Angeles가 무난하다. 남반구(Australia/Sydney)는 전환 방향이 반대라 함께 넣으면 좋다.
5. 전환 시각 근처의 로그를 조사할 때 오프셋을 함께 본다. 폴백 날에는 타임스탬프가 되돌아가는 로그가 정상이다(P1 18장).

꼬리 질문

import UserNotifications

// ❌ 절대 시각 + 86400 반복 — DST 후 8시나 10시에 울린다
let bad = UNTimeIntervalNotificationTrigger(timeInterval: 86400, repeats: true)

// ✅ 달력 성분으로 등록 — 시스템이 매일 지역 시간 09:00 을 계산한다
var comps = DateComponents()
comps.hour = 9
comps.minute = 0
let good = UNCalendarNotificationTrigger(dateMatching: comps, repeats: true)

Q4. 존재하지 않는 시각과 모호한 시각을 API는 어떻게 다루는가?

CS 원리

부분 함수(partial function)를 다루는 방식에는 세 가지 선택지가 있다.

• 실패를 반환 — nil이나 에러. 호출자가 반드시 처리해야 하므로 안전하지만, 흔한 경우에 부담이 크다.
• 가장 가까운 유효 값으로 사상 — 전체 함수로 만든다. 편하지만 조정이 일어났다는 사실이 감춰진다.
• 정책을 파라미터로 — 호출자가 무엇을 원하는지 선언하게 한다. Foundation의 선택이다.

세 번째가 우월한 이유는 정답이 맥락마다 다르기 때문이다. "새벽 2시 30분 알림"이 존재하지 않는 날, 어떤 앱은 건너뛰어야 하고 어떤 앱은 3시 30분에라도 울려야 한다. 라이브러리가 하나를 고를 수 없다.

다만 기본값이 있다는 것이 함정이다. 정책을 명시하지 않으면 라이브러리의 기본 선택이 적용되고, 그 선택이 우리 요구와 다를 수 있다. 그런데 대부분의 날에는 갭·중복이 없으므로 기본값이 무엇인지 모른 채 몇 년이 지나간다.

이것은 P1 21장 Q6에서 본 페일 사일런트 문제의 한 형태다 — 실패가 조용히 성공처럼 처리된다.

iOS에서는

세 파라미터를 명시하는 API가 nextDate(after:matching:matchingPolicy:repeatedTimePolicy:direction:)다.

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "America/Los_Angeles")!

var target = DateComponents(); target.hour = 2; target.minute = 30
let dayBefore = cal.date(from: DateComponents(year: 2026, month: 3, day: 7, hour: 12))!

// 기본 정책 — 다음 유효 시각으로 민다
cal.nextDate(after: dayBefore, matching: target,
             matchingPolicy: .nextTime)
//   3/8 03:30 — 없는 02:30 대신 조정됐다

// 엄격 정책 — 존재하지 않으면 그날을 건너뛴다
cal.nextDate(after: dayBefore, matching: target,
             matchingPolicy: .strict)
//   3/9 02:30 — 전환일을 아예 건너뛴다

중복 시각은 repeatedTimePolicy가 정한다.

let fallBefore = cal.date(from: DateComponents(year: 2026, month: 10, day: 31, hour: 12))!
var t = DateComponents(); t.hour = 1; t.minute = 30

cal.nextDate(after: fallBefore, matching: t,
             matchingPolicy: .nextTime, repeatedTimePolicy: .first)
//   11/1 01:30 PDT — 첫 번째 (DST 적용 중)

cal.nextDate(after: fallBefore, matching: t,
             matchingPolicy: .nextTime, repeatedTimePolicy: .last)
//   11/1 01:30 PST — 두 번째 (표준시)
//   두 결과의 절대 시각은 정확히 1시간 차이다

반복 일정은 직접 루프를 돌리지 말고 enumerateDates에 맡긴다. 정책이 매 반복에 일관되게 적용된다.

var nine = DateComponents(); nine.hour = 9; nine.minute = 0

cal.enumerateDates(startingAfter: start, matching: nine,
                   matchingPolicy: .nextTime,
                   repeatedTimePolicy: .first,
                   direction: .forward) { date, exactMatch, stop in
    guard let date else { return }
    // exactMatch 가 false 면 조정이 일어났다는 뜻이다 — 로깅해 두면 진단에 도움된다
    if !exactMatch { logger.notice("시각 조정됨: \(date)") }
    schedule(at: date)
    if date > end { stop = true }
}

exactMatch 플래그가 중요하다. 조정이 일어났는지를 알려주므로, 페일 사일런트를 페일 라우드로 바꿀 수 있다.

실험 · 도구

정책별 결과를 나란히 찍어 보면 기본값의 영향이 분명해진다.

import Foundation

var cal = Calendar(identifier: .gregorian)
cal.timeZone = TimeZone(identifier: "America/Los_Angeles")!
let fmt = DateFormatter()
fmt.locale = Locale(identifier: "en_US_POSIX"); fmt.timeZone = cal.timeZone
fmt.dateFormat = "MM-dd HH:mm zzz"

let before = cal.date(from: DateComponents(year: 2026, month: 3, day: 7, hour: 12))!
var t = DateComponents(); t.hour = 2; t.minute = 30

for (name, policy) in [("nextTime", Calendar.MatchingPolicy.nextTime),
                       ("nextTimePreservingSmallerComponents", .nextTimePreservingSmallerComponents),
                       ("previousTimePreservingSmallerComponents", .previousTimePreservingSmallerComponents),
                       ("strict", .strict)] {
    let d = cal.nextDate(after: before, matching: t, matchingPolicy: policy)
    print(String(format: "%-42@ %@", name as NSString,
                 (d.map(fmt.string(from:)) ?? "없음") as NSString))
}

기존 코드가 정책을 명시하는지 훑는다.

# 정책을 지정하지 않은 nextDate 호출 — 기본값이 조용히 적용된다
grep -rn "nextDate(after:" --include=*.swift . | grep -v matchingPolicy

# 반복 일정을 직접 루프로 돌리는 곳 — enumerateDates 로 옮길 후보
grep -rn "while.*addingTimeInterval\|for.*byAdding: .day" --include=*.swift .

# nil 을 기대하는 코드 — date(from:) 은 조정해서 값을 돌려준다
grep -rn -A2 "cal.date(from:" --include=*.swift . | grep -i "nil\|guard let\|else"

프로젝트 적용

1. 정책을 항상 명시한다. 기본값에 기대면 그 기본값이 무엇인지 모른 채 몇 년이 지나간다.
2. exactMatch를 확인하고 로깅한다. 조정이 일어난 사실을 남기면 전환일 장애를 사후 판독할 수 있다.
3. 반복 일정은 enumerateDates에 맡긴다. 직접 루프는 정책을 매번 다시 구현하게 만든다.
4. 제품 요구를 먼저 정한다. "없는 시각이면 건너뛴다"와 "밀어서라도 실행한다"는 기능 명세이지 구현 세부가 아니다.
5. 전환일 경계를 단위 테스트에 고정한다. 2026년 기준 America/Los_Angeles의 3/8과 11/1이 대표 케이스다.

꼬리 질문

struct Recurrence: Codable {
    let components: DateComponents      // hour: 9, minute: 0
    let timeZoneID: String              // "Asia/Seoul" — 규칙 해석의 기준
    let policy: String                  // "nextTime" 등 — 정책도 함께 저장한다
}
//   실행 시점에 매번 계산한다. 캐시는 성능용일 뿐 진실의 원천이 아니다.

if !exactMatch {
    logger.notice("일정 조정: 요청 \(requested, privacy: .public) → 실제 \(actual, privacy: .public)")
    metrics.increment("schedule.adjusted")     // 빈도를 지표로 추적한다
}

Q5. DateFormatter는 왜 느리고 무엇을 캐시해야 하는가?

CS 원리

이 문제는 비싼 초기화를 가진 객체를 다루는 고전적 딜레마다.

초기화가 비싸면 재사용하고 싶어진다. 그런데 재사용하려면 공유해야 하고, 공유하면 가변 상태가 여러 곳에서 보인다. 여기서 캐싱과 스레드 안전성이 충돌한다.

해결 방식이 셋 있다.

• 스레드별 인스턴스 — 공유하지 않으면서 재사용한다. 메모리를 더 쓰고 스레드 수만큼 초기화한다.
• 불변으로 만들어 공유 — 설정을 끝낸 뒤 절대 바꾸지 않는다는 규약을 지킨다. 규약이 코드로 강제되지 않는 것이 약점이다.
• 값 타입으로 재설계 — 애초에 공유할 이유를 없앤다. 생성 비용 자체가 작아야 성립한다.

Foundation은 세 번째로 갔다. FormatStyle은 열거형 복사 수준의 생성 비용이라 캐싱이 불필요하고, 값 타입이라 경합이 없다. 비싼 초기화를 없애는 것이 캐싱보다 나은 해법이라는 결론이다.

덧붙여 플랫폼별 보장 차이를 알아야 한다. Linux의 swift-corelibs-foundation은 이 스레드 안전성이 별도 이슈로 보고된 적이 있어, "Foundation이니 당연히 안전하다"고 넘기면 안 된다. 서버 사이드 Swift에서 특히 주의할 지점이다.

iOS에서는

레거시 코드에서 DateFormatter를 유지해야 한다면 불변 공유 규약을 코드로 강제하는 것이 최선이다.

// ✅ 설정을 초기화 시점에 끝내고 이후 노출하지 않는다
enum WireFormat {
    static let iso: DateFormatter = {
        let f = DateFormatter()
        f.locale = Locale(identifier: "en_US_POSIX")
        f.timeZone = TimeZone(secondsFromGMT: 0)
        f.calendar = Calendar(identifier: .gregorian)
        f.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"
        return f                     // 반환 후 아무도 설정을 못 바꾸게 한다
    }()
}

// ❌ 흔한 사고 — 공유 인스턴스의 설정을 그때그때 바꾼다
formatter.dateFormat = "yyyy-MM-dd"     // 다른 스레드가 읽는 중이면 경합
let s = formatter.string(from: date)

더 나은 방향은 값 타입으로 옮기는 것이다. 캐싱 고민 자체가 사라진다.

// 기계용 — 전용 타입
let s = Date().formatted(.iso8601)

// 표시용 — 필드만 요청
let d = Date().formatted(.dateTime.year().month().day())

// 파싱도 같은 스타일로
let back = try Date("2026-08-15T14:30:00Z", strategy: .iso8601)

주의할 점은 "캐시했으니 스레드 안전하다"가 아니라는 것이다. 캐싱은 성능 문제를 풀 뿐이고, 안전성은 설정을 안 바꾼다는 별도 규약에서 온다.

실험 · 도구

18배 차이를 직접 재현해 보자.

import Foundation

let date = Date()
let clock = ContinuousClock()

// (A) 매번 새로 생성
let a = clock.measure {
    for _ in 0..<3_000 {
        let f = DateFormatter()
        f.locale = Locale(identifier: "en_US_POSIX")
        f.dateFormat = "yyyy-MM-dd"
        _ = f.string(from: date)
    }
}

// (B) 한 번 만들어 재사용
let shared = DateFormatter()
shared.locale = Locale(identifier: "en_US_POSIX")
shared.dateFormat = "yyyy-MM-dd"
let b = clock.measure { for _ in 0..<3_000 { _ = shared.string(from: date) } }

// (C) 값 타입
let c = clock.measure { for _ in 0..<3_000 { _ = date.formatted(.iso8601) } }

print("매번 생성: \(a)")   // 약 0.048초
print("캐시:      \(b)")   // 약 0.0027초 — 약 18배
print("FormatStyle: \(c)")

경합 위험이 있는 코드를 찾아낸다.

# 공유 포매터의 설정을 나중에 바꾸는 곳 — 경합 후보
grep -rn -A3 "static let.*Formatter" --include=*.swift . \
  | grep -E "dateFormat *=|timeZone *=|locale *="

# Thread Sanitizer 로 실제 경합을 잡는다 (P0 15장 Q6)
xcodebuild test -scheme App -enableThreadSanitizer YES

프로젝트 적용

1. 새 코드는 FormatStyle을 쓴다. 캐싱·경합 문제가 함께 사라진다.
2. 남겨 둘 DateFormatter는 불변으로 만든다. 생성 클로저 안에서 설정을 끝내고 let으로 노출한다.
3. 공유 포매터의 설정을 런타임에 바꾸지 않는다. 형식이 여러 개면 포매터를 여러 개 만든다.
4. Thread Sanitizer를 CI에 넣는다. 이 계열 경합은 재현이 드물어 수동 테스트로는 안 잡힌다.
5. 서버 사이드 Swift라면 플랫폼 보장을 확인한다. Linux 구현의 안전성이 Apple 플랫폼과 같다고 가정하지 않는다.

꼬리 질문

// 굳이 공유가 필요하면 액터에 가둔다
actor FormatterBox {
    private let f: DateFormatter = { … }()
    func string(from d: Date) -> String { f.string(from: d) }
}
//   다만 await hop 비용이 붙으므로, 값 타입으로 가는 편이 대개 낫다

// 셋 다 같은 결과 — 비용과 안전성이 다르다
ISO8601DateFormatter().string(from: d)          // 매번 생성 — 피한다
sharedISO.string(from: d)                       // 재사용 — 설정 불변 규약 필요
d.formatted(.iso8601)                           // 값 타입 — 고민 없음

// 소수 초가 필요하면 옵션을 붙인다
d.formatted(.iso8601.dateTimeSeparator(.standard))

// ❌ 셀 렌더마다 포매팅 — 스크롤 중 반복된다
cell.dateLabel.text = item.createdAt.formatted(.dateTime.month().day())

// ✅ 모델을 만들 때 한 번만 계산해 담아 둔다
struct Row { let title: String; let dateText: String }
//   다만 로케일 변경 시 재계산이 필요하다 (28장 Q7 꼬리질문)

Q6. 시간 데이터를 어떻게 저장하고 전송해야 하는가?

CS 원리

같은 "시간"이라는 말이 서로 다른 세 가지 개념을 가리킨다. 각각 다른 불변식을 가지므로 표현도 달라야 한다.

세 번째가 특히 간과된다. "2027년 7월 1일 서울 09:00 회의"를 지금 계산한 UTC 값으로 저장하면, 그 사이 한국이 서머타임을 도입할 경우 실제로는 08:00이나 10:00에 열린다. 저장해야 할 것은 계산 결과가 아니라 계산의 입력이다.

여기서 일반 원리가 나온다 — 파생값이 아니라 원본을 저장한다. 절대 시각은 (지역 시각 + 타임존 규칙)에서 계산되는 값이고, 규칙이 바뀔 수 있다면 계산 결과를 굳히면 안 된다.

마지막으로 윤초를 짚어야 한다. Unix time과 Date는 윤초를 의도적으로 무시한다 — 하루는 항상 86,400초다. 2016-12-31에 실제로 윤초가 삽입됐지만, 그 날짜 경계를 Date 차이로 재면 정확히 86400.0초가 나온다. 물리적으로는 86401초가 흘렀는데도 그렇다. 이는 버그가 아니라 설계상의 선택이고, 대부분의 앱에는 문제가 되지 않는다. 다만 정밀한 물리 시간이 필요하면 Date가 답이 아니라는 뜻이다.

iOS에서는

세 개념을 타입으로 갈라두면 호출부에서 헷갈릴 여지가 사라진다.

import Foundation

/// ① 일어난 순간 — 절대 시각
struct Instant: Codable, Comparable {
    let date: Date
    static func < (l: Self, r: Self) -> Bool { l.date < r.date }
}

/// ② 달력 날짜 — 타임존과 무관
struct CalendarDate: Codable, Hashable {
    let year: Int, month: Int, day: Int

    var iso: String { String(format: "%04d-%02d-%02d", year, month, day) }

    /// 특정 타임존에서 이 날짜가 시작하는 절대 시각
    func startOfDay(in tz: TimeZone) -> Date {
        var cal = Calendar(identifier: .gregorian); cal.timeZone = tz
        return cal.date(from: DateComponents(year: year, month: month, day: day))!
    }
}

/// ③ 지역 시각 약속 — 규칙을 저장한다
struct LocalAppointment: Codable {
    let components: DateComponents      // year·month·day·hour·minute
    let timeZoneID: String

    /// 지금의 타임존 규칙으로 절대 시각을 계산한다 — 저장하지 않고 매번 계산
    func resolve() -> Date? {
        guard let tz = TimeZone(identifier: timeZoneID) else { return nil }
        var cal = Calendar(identifier: .gregorian); cal.timeZone = tz
        return cal.date(from: components)
    }
}

JSON 계약도 이 구분을 반영해야 한다. 필드 이름에 의도를 담으면 오해가 줄어든다.

struct Order: Codable {
    let placedAtUTC: Date          // ① 순간 — ISO 8601 로 인코딩
    let deliveryDate: String       // ② 달력 날짜 — "2026-08-20"
    let pickupLocalTime: String    // ③ 지역 시각 — "2026-08-20T14:00"
    let pickupTimeZone: String     // ③ 의 짝 — "Asia/Seoul"
}

let dec = JSONDecoder()
dec.dateDecodingStrategy = .iso8601      // ① 만 Date 로 디코딩된다

흔한 사고 하나 — 생일을 Date로 저장하면 사용자가 해외로 이동했을 때 하루 밀려 보인다. 생일은 순간이 아니라 달력 날짜다.

실험 · 도구

생일이 밀리는 현상을 직접 재현해 보자.

import Foundation

// 서울에서 1990-08-15 자정으로 저장했다고 하자
var seoul = Calendar(identifier: .gregorian)
seoul.timeZone = TimeZone(identifier: "Asia/Seoul")!
let stored = seoul.date(from: DateComponents(year: 1990, month: 8, day: 15))!

// 사용자가 LA 로 이동하면
var la = Calendar(identifier: .gregorian)
la.timeZone = TimeZone(identifier: "America/Los_Angeles")!
let c = la.dateComponents([.year, .month, .day], from: stored)
print("\(c.year!)-\(c.month!)-\(c.day!)")     // 1990-8-14   ← 하루 밀렸다

// 달력 날짜로 저장했다면 어디서 보든 8월 15일이다
let birthday = (year: 1990, month: 8, day: 15)

윤초가 무시되는 것도 확인할 수 있다.

// 2016-12-31 에 윤초가 실제로 삽입됐다
var utc = Calendar(identifier: .gregorian)
utc.timeZone = TimeZone(secondsFromGMT: 0)!
let a = utc.date(from: DateComponents(year: 2016, month: 12, day: 31))!
let b = utc.date(from: DateComponents(year: 2017, month: 1, day: 1))!

print(b.timeIntervalSince(a))     // 86400.0  ← 물리적으로는 86401초가 흘렀다
//   Unix time 은 윤초를 의도적으로 무시한다. 버그가 아니라 설계다.

기존 코드에서 개념이 섞인 곳을 찾는다.

# 날짜 성격 필드가 Date 타입인 곳 — ② 를 ① 로 저장한 후보
grep -rn -E "(birth|anniversar|dueDate|expiryDate).*: *Date" --include=*.swift .

# 미래 일정을 절대 시각으로 저장하는 곳 — ③ 을 ① 로 저장한 후보
grep -rn -E "(scheduledAt|meetingAt|remindAt).*: *Date" --include=*.swift .

프로젝트 적용

1. 필드마다 세 개념 중 어느 것인지 정한다. 스키마 문서에 명시하고 필드 이름에 반영한다 — placedAtUTC, deliveryDate, pickupLocalTime.
2. 달력 날짜를 Date로 저장하지 않는다. 생일·기념일·마감일이 대표적이다. 문자열이나 년·월·일 정수로 저장한다.
3. 미래 일정은 규칙을 저장한다. 절대 시각으로 굳히면 타임존 정책 변경에 취약해진다.
4. 타임스탬프에는 단위를 이름에 넣는다. createdAtMs처럼. 초/밀리초 혼동은 1000배 오차를 낸다.
5. 윤초가 필요한 정밀도라면 Date가 아닌 다른 수단을 쓴다. 대부분의 앱에는 해당하지 않지만, 알고 쓰는 것과 모르고 쓰는 것은 다르다.

꼬리 질문

struct Entry: Codable {
    let at: Date              // 절대 시각
    let timeZoneID: String    // 기록 당시의 타임존
}
//   "홈 기준 통계"와 "현지 기준 통계"를 둘 다 만들 수 있다

func normalizeEpoch(_ raw: Double) -> Date {
    // 2001년~2286년 범위를 초로 해석했을 때 벗어나면 밀리초로 본다
    let asSeconds = Date(timeIntervalSince1970: raw)
    let plausible = (2000...2200)
    var cal = Calendar(identifier: .gregorian); cal.timeZone = TimeZone(secondsFromGMT: 0)!
    let year = cal.component(.year, from: asSeconds)
    return plausible.contains(year) ? asSeconds
                                    : Date(timeIntervalSince1970: raw / 1000)
}

// 저장 당시 KST 자정으로 넣었다면 KST 렌즈로 읽어 날짜를 복원한다
var kst = Calendar(identifier: .gregorian)
kst.timeZone = TimeZone(identifier: "Asia/Seoul")!
let c = kst.dateComponents([.year, .month, .day], from: legacyDate)
let restored = CalendarDate(year: c.year!, month: c.month!, day: c.day!)

출처 · 참고자료