Epoch 변환기 실수: 잘못된 Unix 타임스탬프 변환 피하기

잘못된 날짜를 만드는 일곱 가지 실수

Epoch 변환기는 단순한 산술을 하므로, 출력이 틀릴 때 원인은 거의 계산이 아니라 입력입니다. 타임스탬프에는 그것이 초인지 밀리초인지, UTC인지 로컬인지, 얼마나 정밀한지를 알려 주는 라벨이 없으며, 모든 잘못된 변환은 그중 하나를 잘못 추측하는 데서 옵니다. 가장 빠른 단서는 나온 연도입니다. 1970년 근처나 수천 년 뒤의 날짜는 단위 혼동이고, 맞지만 깔끔한 시간 수만큼 어긋난 날짜는 시간대 실수입니다. 아래 표가 현장 가이드이며, 이어지는 섹션은 단위와 시간대 실수를 자세히 설명하고 변환을 코드로 검증하는 방법을 보여 줍니다.

• Epoch를 날짜로 변환하는 도구 열기

Epoch 변환기가 하는 일

Epoch 변환기는 숫자 타임스탬프를 읽을 수 있는 날짜로 바꾸고, 사람의 날짜를 다시 Epoch 타임스탬프로 바꿉니다. 좋은 변환기는 Unix 초, Unix 밀리초, UTC 출력, 로컬 시간대 출력, ISO 8601 문자열을 처리하며, 값을 코드, 데이터베이스, API 요청에 복사하기 전에 단위를 분명히 합니다. Epoch 변환기, Unix 시간 변환기, Unix 타임스탬프 변환기, Unix 에포크 계산기는 모두 같은 일을 가리킵니다. 1970년 1월 1일 UTC 이후의 초(또는 밀리초) 계수와 사람이 읽을 수 있는 날짜 사이를 번역하는 것입니다. 변환기가 문제인 경우는 드물고, 대개 문제는 입력입니다.

단위 실수: 초, 밀리초, 마이크로, 나노

단연 가장 흔한 변환 오류는 단위 혼동이며, 특징이 있습니다. 날짜가 1970년이 되거나 수천 년 떨어집니다. JavaScript에서 가장 자주 물립니다. Date 생성자와 Date.now()가 모두 밀리초로 동작하는 반면, 대부분의 API, 데이터베이스, Unix date 명령은 초로 동작하기 때문입니다. 10자리 초 값을 1000으로 곱하지 않고 new Date()에 전달하면 53년 일찍 떨어집니다. 반대로, 13자리 밀리초를 초 함수에 먹이면 날짜가 먼 미래로 날아갑니다. 더 높은 정밀도의 소스는 이를 악화시킵니다. 데이터베이스는 흔히 16자리 마이크로초를, 트레이싱 시스템은 19자리 나노초를 내보내며, 둘 다 잘못된 천 년대로 디코딩되기 전까지는 유효한 Unix 값처럼 보입니다.

• 10자리 → 초(예: 1700000000); 13 → 밀리초; 16 → 마이크로초; 19 → 나노초
• JavaScript: new Date(seconds * 1000), 또는 new Date(ms) 직접
• 마이크로초 → 변환 전에 1,000,000으로 나눔; 나노초 → 1,000,000,000으로 나눔
• 상식 점검: 결과는 현재 십 년대의 그럴듯한 날짜여야 함

• MDN — Date() 생성자(밀리초를 기대)
• 밀리초 vs 초 — 단위 완전 가이드

시간대 실수: UTC vs 로컬과 일광 절약 시간

단위가 맞으면 남는 오류는 시간대 오류이며, 이것도 특징을 공유합니다. 날짜는 맞지만 시계가 정수 시간만큼 어긋납니다. Unix 타임스탬프는 자체 시간대가 없는 단일 순간이며, 오프셋은 순간을 형식화할 때만 적용됩니다. 따라서 서로 다른 시간대로 설정된 두 변환기는 같은 숫자에 대해 다른 시계 시간을 표시합니다. 어느 쪽도 틀린 게 아니라 단지 서로 다른 로컬 관점을 보여 줄 뿐입니다. 함정은 어느 시간대에서 왔는지 기록하지 않고 로컬 벽시계 시간을 복사하거나, 일광 절약 전환에 걸린 시간을 변환하는 것입니다. 거기서는 로컬 시간이 두 번 일어나거나 전혀 일어나지 않을 수 있습니다. 결과가 정확히 한 시간 어긋났다면 변환기보다 먼저 일광 절약 시간을 의심하세요.

• 값은 UTC로 비교하고, 로컬 시간대는 표시하는 순간에만 적용
• 로컬 시간은 그 IANA 시간대나 UTC 오프셋을 함께 저장하지 않고 저장하지 말 것
• 일광 절약 전환 근처에서는 모호한 로컬 시간이 아니라 UTC에서 순간을 유도

• IANA 시간대 데이터베이스(모든 런타임이 쓰는 규칙)
• 일광 절약 시간과 Unix 타임스탬프

먼저 방향을 선택하라

대부분의 타임스탬프 작업은 두 방향 중 하나입니다. Epoch에서 날짜로, 또는 날짜에서 Epoch로입니다. 방향을 먼저 정하면 잘못된 테스트 데이터와 깨진 API 페이로드의 가장 흔한 원인 — 올바른 값을 잘못된 방향으로 변환하는 것 — 을 막을 수 있습니다.

• Epoch에서 날짜로: 1700000000을 붙여넣고 UTC 또는 로컬 날짜를 읽음
• 날짜에서 Epoch로: 2026-01-01 00:00:00 UTC를 선택해 1767225600을 얻음
• 결과를 복사하기 전에 대상이 초를 기대하는지 밀리초를 기대하는지 확인

변환 값을 복사하기 전에 확인할 것

변환기는 입력이 모호하지 않은 만큼만 정확할 수 있습니다. 타임스탬프를 테스트, cron 작업, 마이그레이션, API 요청에 복사하기 전에 단위, 시간대, 기대 정밀도를 확인하세요. 가장 빠른 상식 점검은 나온 연도입니다. 1970년 근처나 먼 미래의 날짜는 거의 항상 변환기 오류가 아니라 단위 혼동을 가리킵니다.

• 수신 시스템은 초를 기대하는가, 밀리초를 기대하는가?
• 표시된 날짜는 UTC인가, 로컬 시간인가?
• 그 타임스탬프는 순간을 나타내는가, 로컬 달력 날짜를 나타내는가?
• 데이터베이스 열은 네이티브 datetime, Unix 초, Unix 밀리초 중 무엇을 저장하는가?
• 결과가 1970년 근처이거나 먼 미래인가? 보통 단위 혼동을 가리킨다.

변환을 코드로 검증하라

변환 값이 중요할 때 — 마이그레이션, 청구 경계, cron 스케줄 — 단일 도구를 신뢰하지 마세요. 같은 순간을 자신의 런타임에서 다시 유도하고 둘이 UTC에서 일치하는지 확인하세요. 다음 각 줄은 Z 접미사가 붙은 모호하지 않은 ISO 8601 문자열을 출력하므로, 비교할 로컬 시간대 추측이 없습니다.

• JavaScript: new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
• Python: datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
• Shell (GNU): date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'
• 도구와 런타임이 어긋나면, 의심할 것은 입력의 단위나 시간대이지 변환기가 아니다

• Python — datetime.fromtimestamp
• Unix 시간을 날짜로 — 모든 언어의 변환 레시피

실제 예: 하나의 순간, 세 가지 표현

순간 2026-01-01 00:00:00 UTC를 봅시다. Unix 초로는 1767225600, Unix 밀리초로는 1767225600000, ISO 8601로는 2026-01-01T00:00:00Z입니다. 셋 다 같은 순간을 나타내며 형식과 단위만 다릅니다. 순간은 결코 자체 시간대를 갖지 않습니다. 뉴욕은 같은 값을 2025-12-31 19:00:00으로 표시합니다. 오프셋은 표시할 때 적용되며 숫자에 저장되지 않기 때문입니다.

관련 글

• 흔한 Unix 타임스탬프 버그 10가지(코드 속 같은 문제)
• 밀리초 vs 초 — 단위 혼동
• 일광 절약 시간과 Unix 타임스탬프
• 2038년 문제
• Unix 시간을 날짜로
• Epoch를 날짜로 변환하는 도구