서머타임

서머타임은 여름 동안 시계를 한 시간 앞당겨 쓰는 제도입니다. 해가 일찍 뜨는 철에 밝은 시간을 저녁 쪽으로 옮기려는 것입니다. 이 제도를 쓰는 지역은 봄과 가을에 한 번씩 시계를 한 시간 옮깁니다. 그 두 날에는 지역 시각으로 적은 기록과 예약 작업이 어긋나기 쉽습니다.

상세

이 절은 서머타임이 시계를 어떻게 옮기는지부터 봅니다. 런던 시각 하나를 들고 봄과 가을의 전환일을 따라가며, 없는 시각과 두 번 오는 시각이 어떻게 생기는지 표로 확인합니다. 그다음 백엔드 코드가 이 두 날에 어디서 틀리는지, 그리고 어떻게 피하는지를 봅니다.

서머타임은 여름 동안 지역 시계를 한 시간 앞당겨 쓰는 제도입니다. 서머타임(summer time)은 영국식 이름입니다. 미국에서는 일광 절약 시간(Daylight Saving Time, DST)이라고 부릅니다.

런던은 봄에 3월 마지막 일요일 새벽 1시가 되는 순간 시계를 2시로 돌립니다. 가을에는 10월 마지막 일요일 새벽 2시가 되는 순간 1시로 되돌립니다.

시계를 앞당기는 까닭

여름에는 해가 일찍 뜹니다. 해가 뜬 뒤 몇 시간 동안 대부분의 사람은 아직 잡니다. 시계를 한 시간 앞당기면 모두가 한 시간 일찍 일어나 한 시간 일찍 일을 마칩니다. 밝은 한 시간이 새벽에서 저녁으로 옮겨 가는 셈입니다.

처음 내세운 명분은 저녁 조명에 드는 연료와 전기를 아끼는 것이었습니다. 얼마나 아끼는지는 지금도 논란입니다. 서머타임을 쓰는 나라와 안 쓰는 나라가 섞여 있습니다. 한국도 서머타임을 쓰다가 그만둔 나라입니다.

철마다 바뀌는 UTC 오프셋

UTC(Coordinated Universal Time, 협정 세계시)는 전 세계가 함께 쓰는 기준 시각입니다. 서울과 런던의 시계가 서로 달라도, UTC 로 적으면 같은 순간은 같은 값이 됩니다.

나라마다 쓰는 지역 시각은 UTC 에 몇 시간을 더하거나 빼서 얻습니다. 이 차이를 UTC 오프셋이라고 부릅니다. 한국은 지금 서머타임을 쓰지 않아서 오프셋이 한 해 내내 +09:00 입니다. 서울이 오후 6시면 UTC 는 언제나 오전 9시입니다.

서머타임을 쓰는 지역은 오프셋이 철마다 바뀝니다. 런던은 겨울에 +00:00, 여름에 +01:00 입니다. 서울과 런던의 시차는 겨울에 아홉 시간, 여름에 여덟 시간이 됩니다.

서머타임이 아닌 기간에 쓰는 시각을 표준시라고 부릅니다. 서머타임 기간에 쓰는 시각은 표준시에 한 시간을 얹은 시각입니다. 아래 그림은 런던이 한 해 동안 두 기간을 오가는 모습입니다.

stateDiagram-v2
    state "표준시 기간 (오프셋 +0시간)" as 표준
    state "서머타임 기간 (오프셋 +1시간)" as 여름
    [*] --> 표준
    표준 --> 여름 : 3월 말 · 새벽 1시에 2시로
    여름 --> 표준 : 10월 말 · 새벽 2시에 1시로

봄에 사라지는 한 시간

봄 전환일의 런던 시계를 UTC 와 나란히 놓아 봅니다. 왼쪽 칸이 UTC 이고, 오른쪽 칸이 같은 순간의 런던 시각입니다.

UTC 로는 1분이 흘렀습니다. 그사이 런던 시계는 00:59 에서 02:00 으로 건너뜁니다. 그날 런던에는 01:00 부터 01:59 까지가 없습니다. 「런던 시각 01:30」이라는 값을 받으면 가리킬 순간이 없습니다.

날짜 라이브러리마다 이런 값을 다루는 방식이 다릅니다. Java 날짜 라이브러리의 ZonedDateTime.of 는 이 값을 한 시간 늦춰 02:30 으로 해석합니다. 오프셋까지 함께 받는 ZonedDateTime.ofStrict 는 같은 값에 오류를 냅니다.

cron 은 정해진 시각에 명령을 실행해 주는 예약 작업 도구입니다. 매일 새벽 01:30 에 도는 작업은 봄 전환일에 돌 시각이 오지 않습니다. 리눅스 배포판이 흔히 쓰는 Vixie cron 은 시계가 넘어간 직후에 돌립니다. 그날을 건너뛰는 도구도 있습니다.

가을에 두 번 오는 한 시간

가을 전환일도 같은 꼴로 놓아 봅니다.

런던 시계는 02:00 에 닿는 순간 01:00 으로 돌아갑니다. 01:00 부터 01:59 까지가 두 번 흐릅니다. 「런던 시각 01:30」은 이날 한 시간 떨어진 두 순간을 가리킵니다. 오프셋이 같이 적혀 있지 않으면 둘 중 어느 쪽인지 알 수 없습니다.

지역 시각으로 찍은 로그는 이날 시간이 거꾸로 흐르는 것처럼 보입니다. 01:59 다음 줄이 01:00 입니다. 시각 순으로 정렬하면 두 시간치 기록이 뒤섞입니다.

새벽 01:30 에 도는 예약 작업은 도구에 따라 이날 두 번 돕니다. 그래서 이런 작업은 두 번 돌아도 결과가 같게 짜 둡니다. 이 성질을 멱등성이라고 부릅니다.

하루가 24시간이 아닌 날

봄 전환일의 런던은 하루가 23시간입니다. 가을 전환일은 25시간입니다. 이 두 날에는 「하루 뒤」와 「24시간 뒤」가 서로 다른 시각을 가리킵니다.

아래는 Java 날짜 라이브러리로 봄 전환일 전날 오전 9시에서 출발해 두 가지로 더해 본 것입니다. 줄마다 오른쪽 주석이 그 줄이 내는 런던 시각과 오프셋입니다.

코드 첫 줄의 Europe/London 은 런던의 시간대 이름입니다. 시간대는 한 지역의 오프셋과 서머타임 규칙을 묶은 것입니다. 아래 「규칙을 정하는 곳」 절에서 다시 풉니다.

ZoneId london = ZoneId.of("Europe/London");
ZonedDateTime t = ZonedDateTime.of(
    2026, 3, 28, 9, 0, 0, 0, london);
t.plusDays(1);    // 3/29 09:00 +01:00
t.plusHours(24);  // 3/29 10:00 +01:00

plusDays(1) 은 달력의 날짜를 하루 넘기고 시계 바늘 09:00 을 지킵니다. plusHours(24) 는 흐른 시간 24시간을 더합니다. 그 사이 시계가 한 시간을 건너뛰었으므로 시계로는 10:00 이 됩니다.

어느 쪽이 맞는지는 무엇을 원하느냐가 정합니다. 「매일 아침 9시 알림」이면 하루 뒤가 맞습니다. 「발급하고 24시간 동안 쓸 수 있는 토큰」이면 24시간 뒤가 맞습니다.

지역 날짜로 하루치를 모으는 집계도 이 두 날에 모양이 달라집니다. 시간별로 나눈 칸이 봄에는 23개, 가을에는 25개가 됩니다.

컴퓨터 안의 시각 값

서머타임은 컴퓨터가 세는 시각 값을 건드리지 않습니다. 운영체제는 시각을 에포크부터 흐른 초 수로 셉니다. 에포크는 UTC 기준 1970-01-01 00:00 으로 정해 둔 출발 순간입니다. 이 초 수는 UTC 를 따라 흐르므로 전환일에도 고르게 늘어납니다.

바뀌는 것은 그 초 수를 사람이 읽는 지역 시각으로 옮기는 단계뿐입니다. 옮길 때 더하는 오프셋이 전환 순간에 바뀝니다. 그래서 서머타임 버그는 대개 지역 시각을 저장하거나 지역 시각끼리 계산하는 코드에서 납니다.

규칙을 정하는 곳

서머타임을 쓸지, 언제 시계를 옮길지는 각 나라 정부가 정합니다. 이 규칙은 바뀝니다. 서머타임을 새로 두기도 하고, 없애기도 하고, 전환 날짜를 옮기기도 합니다.

그래서 오프셋 숫자 하나로는 한 지역을 나타낼 수 없습니다. +01:00 만 보고는 그곳이 여름의 런던인지 겨울의 파리인지 모릅니다. 내일의 오프셋이 무엇일지도 알 수 없습니다.

이 규칙을 지역마다 모은 묶음이 앞에서 본 시간대입니다. 시간대에는 Europe/London, Asia/Seoul 같은 이름이 붙습니다. 이 이름이 있으면 어느 날이든 그날의 오프셋을 셈할 수 있습니다.

세계 시간대의 규칙과 그 변경 이력을 모아 둔 공개 자료가 시간대 데이터베이스입니다. 운영체제와 언어 런타임은 이 자료의 사본을 들고 다닙니다. 어느 나라가 규칙을 바꾸면 사본도 새 판으로 올려야 그날부터 시각이 맞습니다.

나라마다 다른 전환 날짜

서머타임은 주로 위도가 높은 지역에서 씁니다. 적도에 가까울수록 철마다 낮 길이가 별로 안 바뀌어 시계를 옮길 까닭이 적습니다.

남반구는 계절이 반대입니다. 북반구가 겨울일 때 남반구 도시가 시계를 앞당깁니다. 시드니는 10월에 시계를 앞당깁니다. 4월에는 되돌립니다.

두 반구의 도시가 모두 서머타임을 쓰면 둘 사이의 시차는 한 해에 네 번 바뀝니다. 어느 한쪽이 시계를 옮길 때마다 한 시간씩 늘거나 줄기 때문입니다.

같은 북반구라도 전환 날짜가 다릅니다. 미국은 유럽보다 봄에 몇 주 먼저 시계를 앞당깁니다. 가을에는 한 주 늦게 되돌립니다. 그 사이 뉴욕과 런던의 시차는 평소의 다섯 시간에서 네 시간으로 줄어듭니다.

두 도시의 시차는 고정값이 아닙니다. 날짜마다 두 도시의 시간대 규칙으로 셈해야 합니다.

백엔드가 전환일을 견디는 방법

이미 일어난 일의 시각은 UTC 로 저장합니다. 로그, 주문, 결제 기록이 그렇습니다. UTC 에는 서머타임이 없어서 사라지는 시각도 두 번 오는 시각도 없습니다.

지역 시각은 사람에게 보여 줄 때만 만듭니다. 저장해 둔 UTC 값에 보는 사람의 시간대를 적용해 바꿉니다. 사용자마다 시간대 이름을 따로 저장해 두는 까닭이 이것입니다.

앞으로 열릴 약속은 다르게 다룹니다. 「내년 여름 런던 오전 9시 회의」를 지금 UTC 로 바꿔 두면, 그 사이 규칙이 바뀔 때 어긋납니다. 이런 값은 지역 시각과 시간대 이름을 같이 저장합니다. 쓸 때마다 그날의 규칙으로 셈합니다.

서버의 시스템 시간대는 흔히 UTC 로 둡니다. 그러면 서버에서 도는 예약 작업이 전환일에 흔들리지 않습니다. 지역 시각에 맞춰 돌아야 하는 작업만 시간대를 따로 지정합니다.

시각을 문자열로 주고받을 때는 오프셋을 같이 적습니다. 가을 전환일의 두 01:30 은 2026-10-25T01:30+01:00 과 2026-10-25T01:30+00:00 으로 갈립니다. 두 문자열은 한 시간 떨어진 두 순간을 가리킵니다.

관련 항목

서머타임이 옮기는 시각과 오프셋

지역 시각 · 표준시 · UTC 오프셋 · 시간대 · 한국 표준시 · UTC

서머타임 규칙을 기록하고 나르는 데이터베이스와 라이브러리

시간대 데이터베이스 · IANA · zoneinfo · java.time · 시간대 이름

서머타임과 무관하게 흐르는 기준 시계

에포크 · 유닉스 시간 · 벽시계 · 단조 시계 · 시계 동기화 · NTP

서머타임 전환일에 흔들리는 예약 작업과 대비책

cron · 스케줄러 · 배치 처리 · 멱등성 · 중복 실행

오프셋을 붙여 시각을 적는 표준 형식

ISO 8601 · RFC 3339 · 타임스탬프 · 날짜 형식

서머타임과 함께 시각 계산을 까다롭게 만드는 달력 규칙

윤초 · 윤년 · 그레고리력 · 타임스케일