[EXT-001][입문] 날짜와 시간대를 헷갈리지 않게 다루기
페이지 정보
작성자 기술팀장 작성일 26-09-06 22:33 조회 40 댓글 0본문
[이번 수업]
서버와 앱을 연결할 때 자주 어긋나는 날짜와 시각을 다룹니다. 같은 순간을 UTC와 지역 시각으로 표현하고 안전하게 비교하는 방법을 로컬 Python 실습으로 익힙니다. 216개 핵심 과정의 공통 선수지식을 보강하는 첫 확장 수업입니다.
[선수지식]
CORE-004의 데이터 표현과 PY-002의 문자열·불리언을 알면 좋습니다. Python 파일을 만들고 실행할 수 있으면 충분합니다.
[학습목표]
1. 순간, 달력 시각, UTC, 오프셋, 시간대의 차이를 설명합니다.
2. RFC 3339 형식의 시각을 읽고 UTC로 바꿉니다.
3. 시간대 없는 값을 거부하고 같은 순간끼리 비교합니다.
[핵심개념]
`2026-09-06 12:34`라는 글자만으로는 어느 지역의 시각인지 알 수 없습니다. 순간은 실제 시간축의 한 지점이고, 달력 시각은 그 순간을 특정 지역 규칙으로 표시한 모습입니다. UTC는 세계 시각의 기준이며 `Z`는 UTC를 뜻합니다. `+09:00`은 현지 시각이 UTC보다 9시간 빠르다는 오프셋입니다. 따라서 `2026-09-06T12:34:56+09:00`과 `2026-09-06T03:34:56Z`는 같은 순간입니다.
RFC 3339는 인터넷에서 날짜와 시각을 주고받는 형식을 정의합니다. `T`는 날짜와 시각을 나누고, 끝에는 `Z` 또는 `+09:00` 같은 UTC 오프셋을 둡니다. Python의 aware datetime은 시간대 정보를 가진 시각이고, naive datetime은 그 정보가 없는 시각입니다. 둘을 섞으면 비교 오류나 잘못된 해석이 생깁니다.
오프셋과 시간대도 다릅니다. `+09:00`은 한 시점의 차이이고 `Asia/Tokyo` 같은 IANA 이름은 지역 규칙을 담습니다. 일광절약시간 지역은 같은 시각이 두 번 나타나거나 건너뛸 수 있습니다. 예약은 지역 시간대도 보존하고 시스템 간 교환과 로그는 UTC로 정규화합니다.
[따라하기]
빈 폴더에 time_check.py를 만들고 아래 코드를 저장합니다. 외부 패키지와 네트워크는 사용하지 않습니다.
```python
from datetime import datetime, timezone
text = "2026-09-06T12:34:56+09:00"
local_time = datetime.fromisoformat(text)
if local_time.tzinfo is None:
raise ValueError("UTC 오프셋이 필요합니다")
utc_time = local_time.astimezone(timezone.utc)
print("입력:", local_time.isoformat())
print("UTC :", utc_time.isoformat().replace("+00:00", "Z"))
print("같은 순간:", local_time.timestamp() == utc_time.timestamp())
```
macOS와 Linux에서는 `python3 time_check.py`, Windows에서는 `py time_check.py`를 실행합니다. 예상 결과는 다음과 같습니다.
```text
입력: 2026-09-06T12:34:56+09:00
UTC : 2026-09-06T03:34:56Z
같은 순간: True
```
프로그램은 입력 문자열을 시간대가 있는 객체로 바꾼 뒤 UTC로 변환합니다. `timestamp()` 비교가 참인 것은 표현은 달라도 같은 순간이기 때문입니다. 지역의 계절별 규칙이 필요하면 표준 라이브러리 `zoneinfo.ZoneInfo`와 IANA 시간대 이름을 사용하세요. 일부 Windows 환경에는 IANA 시간대 데이터가 없을 수 있으므로 Python 공식 문서에 따라 `tzdata` 패키지를 의존성에 명시해야 합니다.
[흔한 실수]
서버가 있는 지역의 시각을 UTC라고 가정하거나, 오프셋 없는 문자열을 임의로 해석하지 마세요. `Z`를 단순히 지우면 UTC가 현지 시각으로 바뀐 것이 아니라 정보만 사라집니다. 날짜만 필요한 생일과 정확한 순간이 필요한 결제 시각도 같은 자료형으로 처리하지 않는 편이 안전합니다. 일광절약시간제가 있는 예약에는 고정 오프셋만 저장하지 말고 지역 시간대도 보존하세요.
[보안 주의]
토큰 만료, 인증서 검사, 감사 로그는 정확한 시각에 의존합니다. 운영 장비의 시스템 시각을 실습 목적으로 바꾸지 말고 본인 소유의 로컬 파일과 고정 예제만 사용하세요. 외부 입력은 허용 형식을 검사하고, 시각 파싱 실패를 조용히 현재 시각으로 대체하지 않습니다. 로그에는 UTC 시각을 남기되 비밀번호·토큰 같은 비밀정보는 기록하지 마세요.
[직접 해볼 과제]
`2026-09-06T03:34:56Z`, `2026-09-05T20:34:56-07:00`, `2026-09-06T12:34:56+09:00`을 목록으로 만들고 모두 UTC로 변환하세요. 세 값이 같은 순간인지 확인한 뒤 오프셋 없는 `2026-09-06T12:34:56`은 오류로 거부해 보세요.
[확인문제]
1. `Z`와 `+09:00`은 각각 무엇을 뜻하나요?
2. 오프셋과 IANA 시간대 이름은 어떻게 다른가요?
3. 시간대 없는 시각을 서버의 현지 시각으로 추측하면 왜 위험한가요?
[다음 학습]
다음 확장 수업에서는 프로그램이 다루는 숫자의 정밀도와 반올림을 살펴봅니다. 금액과 측정값이 계산 과정에서 달라지는 이유를 작은 예제로 확인합니다.
[공식 참고 자료]
RFC 3339 인터넷 날짜와 시각 형식
https://www.rfc-editor.org/rfc/rfc3339.html
IANA Time Zone Database
https://www.iana.org/time-zones
Python datetime 공식 문서
https://docs.python.org/3/library/datetime.html
Python zoneinfo 공식 문서
https://docs.python.org/3/library/zoneinfo.html
PEP 495 지역 시각의 중복 구분
https://peps.python.org/pep-0495/
서버와 앱을 연결할 때 자주 어긋나는 날짜와 시각을 다룹니다. 같은 순간을 UTC와 지역 시각으로 표현하고 안전하게 비교하는 방법을 로컬 Python 실습으로 익힙니다. 216개 핵심 과정의 공통 선수지식을 보강하는 첫 확장 수업입니다.
[선수지식]
CORE-004의 데이터 표현과 PY-002의 문자열·불리언을 알면 좋습니다. Python 파일을 만들고 실행할 수 있으면 충분합니다.
[학습목표]
1. 순간, 달력 시각, UTC, 오프셋, 시간대의 차이를 설명합니다.
2. RFC 3339 형식의 시각을 읽고 UTC로 바꿉니다.
3. 시간대 없는 값을 거부하고 같은 순간끼리 비교합니다.
[핵심개념]
`2026-09-06 12:34`라는 글자만으로는 어느 지역의 시각인지 알 수 없습니다. 순간은 실제 시간축의 한 지점이고, 달력 시각은 그 순간을 특정 지역 규칙으로 표시한 모습입니다. UTC는 세계 시각의 기준이며 `Z`는 UTC를 뜻합니다. `+09:00`은 현지 시각이 UTC보다 9시간 빠르다는 오프셋입니다. 따라서 `2026-09-06T12:34:56+09:00`과 `2026-09-06T03:34:56Z`는 같은 순간입니다.
RFC 3339는 인터넷에서 날짜와 시각을 주고받는 형식을 정의합니다. `T`는 날짜와 시각을 나누고, 끝에는 `Z` 또는 `+09:00` 같은 UTC 오프셋을 둡니다. Python의 aware datetime은 시간대 정보를 가진 시각이고, naive datetime은 그 정보가 없는 시각입니다. 둘을 섞으면 비교 오류나 잘못된 해석이 생깁니다.
오프셋과 시간대도 다릅니다. `+09:00`은 한 시점의 차이이고 `Asia/Tokyo` 같은 IANA 이름은 지역 규칙을 담습니다. 일광절약시간 지역은 같은 시각이 두 번 나타나거나 건너뛸 수 있습니다. 예약은 지역 시간대도 보존하고 시스템 간 교환과 로그는 UTC로 정규화합니다.
[따라하기]
빈 폴더에 time_check.py를 만들고 아래 코드를 저장합니다. 외부 패키지와 네트워크는 사용하지 않습니다.
```python
from datetime import datetime, timezone
text = "2026-09-06T12:34:56+09:00"
local_time = datetime.fromisoformat(text)
if local_time.tzinfo is None:
raise ValueError("UTC 오프셋이 필요합니다")
utc_time = local_time.astimezone(timezone.utc)
print("입력:", local_time.isoformat())
print("UTC :", utc_time.isoformat().replace("+00:00", "Z"))
print("같은 순간:", local_time.timestamp() == utc_time.timestamp())
```
macOS와 Linux에서는 `python3 time_check.py`, Windows에서는 `py time_check.py`를 실행합니다. 예상 결과는 다음과 같습니다.
```text
입력: 2026-09-06T12:34:56+09:00
UTC : 2026-09-06T03:34:56Z
같은 순간: True
```
프로그램은 입력 문자열을 시간대가 있는 객체로 바꾼 뒤 UTC로 변환합니다. `timestamp()` 비교가 참인 것은 표현은 달라도 같은 순간이기 때문입니다. 지역의 계절별 규칙이 필요하면 표준 라이브러리 `zoneinfo.ZoneInfo`와 IANA 시간대 이름을 사용하세요. 일부 Windows 환경에는 IANA 시간대 데이터가 없을 수 있으므로 Python 공식 문서에 따라 `tzdata` 패키지를 의존성에 명시해야 합니다.
[흔한 실수]
서버가 있는 지역의 시각을 UTC라고 가정하거나, 오프셋 없는 문자열을 임의로 해석하지 마세요. `Z`를 단순히 지우면 UTC가 현지 시각으로 바뀐 것이 아니라 정보만 사라집니다. 날짜만 필요한 생일과 정확한 순간이 필요한 결제 시각도 같은 자료형으로 처리하지 않는 편이 안전합니다. 일광절약시간제가 있는 예약에는 고정 오프셋만 저장하지 말고 지역 시간대도 보존하세요.
[보안 주의]
토큰 만료, 인증서 검사, 감사 로그는 정확한 시각에 의존합니다. 운영 장비의 시스템 시각을 실습 목적으로 바꾸지 말고 본인 소유의 로컬 파일과 고정 예제만 사용하세요. 외부 입력은 허용 형식을 검사하고, 시각 파싱 실패를 조용히 현재 시각으로 대체하지 않습니다. 로그에는 UTC 시각을 남기되 비밀번호·토큰 같은 비밀정보는 기록하지 마세요.
[직접 해볼 과제]
`2026-09-06T03:34:56Z`, `2026-09-05T20:34:56-07:00`, `2026-09-06T12:34:56+09:00`을 목록으로 만들고 모두 UTC로 변환하세요. 세 값이 같은 순간인지 확인한 뒤 오프셋 없는 `2026-09-06T12:34:56`은 오류로 거부해 보세요.
[확인문제]
1. `Z`와 `+09:00`은 각각 무엇을 뜻하나요?
2. 오프셋과 IANA 시간대 이름은 어떻게 다른가요?
3. 시간대 없는 시각을 서버의 현지 시각으로 추측하면 왜 위험한가요?
[다음 학습]
다음 확장 수업에서는 프로그램이 다루는 숫자의 정밀도와 반올림을 살펴봅니다. 금액과 측정값이 계산 과정에서 달라지는 이유를 작은 예제로 확인합니다.
[공식 참고 자료]
RFC 3339 인터넷 날짜와 시각 형식
https://www.rfc-editor.org/rfc/rfc3339.html
IANA Time Zone Database
https://www.iana.org/time-zones
Python datetime 공식 문서
https://docs.python.org/3/library/datetime.html
Python zoneinfo 공식 문서
https://docs.python.org/3/library/zoneinfo.html
PEP 495 지역 시각의 중복 구분
https://peps.python.org/pep-0495/
댓글목록 0
등록된 댓글이 없습니다.