MySQL timestamp와 Y2K38 문제

Y2K와 Y2K20에 이어 날짜·시간 시스템의 마지막 큰 이슈로 Y2K38 Problem을 짚는다. 유닉스 시간은 UTC 기준 1970년 1월 1일부터의 초를 32비트 정수로 저장하므로, 2038년 1월 19일 03:14:07에 2,147,483,647을 찍고 그 다음 초부터 오버플로우가 발생한다.

이 한계는 OS, 애플리케이션, 데이터베이스, 바이너리 파일 등 유닉스 타임스탬프를 쓰는 모든 영역에 영향을 준다. 글에서는 32비트 Linux와 C 프로그램에서 실제로 2038년을 넘기면 시간이 1901년으로 되돌아가는 예시를 보여 주고, 64-bit 환경에서는 같은 테스트가 정상 동작함을 비교한다.

MySQL에서도 timestamp는 유닉스 시간과 같은 방식이라 같은 문제가 생긴다. 반면 datetime은 UTC 변환과 2038년 제한의 영향을 덜 받으며, 저장 공간은 datetime이 5 bytes + fractional seconds, timestamp가 4 bytes + fractional seconds로 설명된다.

실제 테스트에서는 MySQL 8.0.27에서 unix_timestamp('2038-01-19 03:14:08')가 0으로 돌아가지만, 8.0.28에서는 같은 값이 2147483648, 2147483649처럼 정상적으로 계산된다. 개선의 핵심은 my_time.h가 새 헤더 **my_time_t.h**를 참조하고, 시간 타입을 int64_t 기반으로 확장한 점이다.

정리하면, MySQL timestamp의 Y2K38 대응 여부는 버전과 구성요소별로 다르며, 실제 운영 환경에서는 다음을 확인해야 한다.

• 2038-01-19 03:14:07 이후 시간을 처리할 수 있는지
• 사용 중인 MySQL 버전이 64-bit time 처리를 지원하는지
• timestamp 대신 datetime이 더 적합한지
• OS, 라이브러리, 애플리케이션, 스키마가 같은 기준으로 업그레이드되었는지