【2038년 문제】TIMESTAMP형의 최대치는 2038-01-09 03:14:07(UTC)【조심해】

TIMESTAMP 형의 최대치를 알았다

어느 DB의 일시 칼럼에 대해서, 시험에 「2500년」이라고 먼 미래의 일시를 설정하려고 하면, MySQL의 에러가 나와 반영되지 않는다, 라고 하는 문제가 있었습니다.

원인을 조사한 결과 MySQL의 날짜와 시간 유형 중 하나 인 TIMESTAMP는 최대 값이 2038-01-09 03:14:07 (UTC)임을 발견했습니다.
9999-99-99...가 최대가 아니고, 설마 상한이 있었다고는…

이 사양에 의해, 2038년을 지나면 다양한 시스템이 동작 불량이 되는 것이 아닐까라고 알려져 있는 것이, 2038년 문제라고 합니다.
https://ko.wikipedia.org/wiki/2038년 문제

왜【2038년】인가

왜 이 최대치가 깨끗한 시간이 아닌가 하면 그 이유도 Wikipedia에 쓰여져 있었습니다.

전통적인 구현에서는 time_t를 int로 하고, 그 int는 부호 첨부 32비트였다. 이 때문에 최대치는 (2^31 - 1) = 2,147,483,647이 되어 취급할 수 있는 것은 2,147,483,647초(≒68년)까지에 한정되어 있었다. 이것을 전제로 작성된 프로그램은, 협정 세계시에 있어서의 1970년 1월 1일 0시 0분 0초(일본 표준시에서는 1970년 1월 1일 9시 0분 0초)로부터 2,147,483,647초를 경과한, 2038년 1월 19일 3시 14분 7초(일본 표준시에서는 2038년 1월 19일 12시 14분 7초, 윤초는 고려하지 않는다)를 지나면, 이 값이 오버플로우 해, 부와 취급 따라서 [2] 시간을 올바르게 취급하고 있다고 가정하는 코드가 있으면 오작동합니다.

부호 첨부 32비트였기 때문에, 이런 어중간한 기간이 되고 있다고 합니다.
TIMESTAMP는 2038년에 폭발하는 시한폭탄 이었네요…

그래서 특히 문제가 없으면 TIMESTAMP가 아니라 DATETIME을 사용하도록합시다!
(DATETIME의 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59')

＊추기＊
코멘트에서 지적해 주셨습니다만, DATETIME형은 타임 존의 영향을 받지 않는다고 하는 문제가 있다고 합니다.
ぃ tp // 이 m / 유바 / ms / 7852 A 29d63d6279c6f6

TIMESTAMP 형을 계속 사용하여 MySQL이 대응해 줄 때까지 기다리거나,
만약 지금도 2038년 이후의 설정을 사용한다면, PostgreSQL로 환승하는 것이 좋을 것 같습니다!
ぃ tp // 코 m / j 타카스 류지 / ms / 5 50 8f298613f99c870 # _ 레후 렌세 89d14067d7440 88 엣 b