에포크 시간 변환기 (Unix, FILETIME, Excel)
시간
운영체제와 앱마다 시간을 '어떤 영점에서 흐른 초(혹은 어떤 단위)' 로 측정하지만 ─ 각자 다른 영점을 택했습니다. Unix 는 1970-01-01 UTC. NTP 는 1900-01-01 UTC. Windows NT 는 1601-01-01 UTC 를 잡고 100 나노초 단위로 카운트(FILETIME). .NET DateTime ticks 는 0001-01-01 부터 100 나노초 단위. Classic Mac OS HFS+ 는 1904-01-01 초 단위. Apple Cocoa CFAbsoluteTime 은 2001-01-01 초 단위. Microsoft Windows Excel 은 1899-12-30 부터 일 단위(Lotus 1-2-3 가 1900 을 윤년으로 잘못 처리한 버그를 Excel 이 호환을 위해 그대로 계승); Mac Excel 은 1904-01-01 부터. 사람이 읽는 형식도 있죠: ISO 8601 ('2026-06-05T00:00:00.000Z'), RFC 2822 ('Fri, 05 Jun 2026 00:00:00 GMT'). SQL Server BIGINT, Windows 이벤트 로그, Numbers 에서 내보낸 CSV 가 모두 같은 순간을 다른 형식으로 표현할 때 ─ 서로 번역이 필요합니다. 이 도구가 한 번에 처리: 왼쪽에서 형식 선택, 값 붙여넣기, 다른 모든 형식이 올바른 에포크 오프셋과 단위로 즉시 렌더. FILETIME 과 .NET ticks 는 BigInt 연산으로 처리해 JavaScript 53 비트 부동소수점이 넘치는 먼 미래 날짜에도 정밀도가 살아남습니다.
변환 세부 정보
내부 정규 값: 1970-01-01 UTC 부터의 JavaScript 밀리초(53 비트 부동소수점, 1970 기준 ±285 614 년 유효). FILETIME 과 .NET ticks 는 BigInt 연산으로 정확한 정수 정밀도 유지. Excel 1900 은 오프셋 25569(1899-12-30 부터 1970-01-01) 사용 ─ 1900-03-01 이후 모든 날짜에 정확하며 Lotus 의 가상 1900-02-29 는 조용히 무시합니다. ISO 8601 과 RFC 2822 출력은 항상 UTC/GMT.
사용법
- 드롭다운에서 소스 형식 선택(기본: ISO 8601, 현재 시각).
- 해당 형식으로 값 입력/붙여넣기 ─ 11 개 표현이 즉시 갱신.
- 형식 드롭다운 전환으로 변환: 표시된 값이 새 형식으로 입력란을 다시 채웁니다.
- 프리셋으로 흔한 기준 시점 입력: 현재·Unix 에포크(1970)·Y2K·Y2038 문제·NTP 32 비트 롤오버(2036-02-07).
- 각 행의 복사 버튼으로 해당 표현을 클립보드로 복사.
자주 묻는 질문
- Excel 1900 시리얼은 왜 1900-01-01 이 아니라 1899-12-30 부터 세나요?
- Lotus 1-2-3 가 1900 을 윤년으로 잘못 처리(실제로는 아님 ─ 1900 ÷ 100 = 19 나머지 0 이지만 1900 ÷ 400 ≠ 정수이므로 그레고리력 규칙상 윤년 제외). Microsoft 는 Excel 구축 시 스프레드시트 호환을 위해 Lotus 버그를 그대로 복사 ─ 그래서 Excel 엔 가상의 1900-02-29 가 존재합니다. 1900-03-01 이후 모든 날짜에 깔끔하게 동작하도록 25569(1899-12-30 부터 1970-01-01 까지의 일수) 오프셋을 사용 ─ 실제 모든 날짜에 올바른 결과를 줍니다. Excel 의 1900-03-01 이전 날짜는 하루 어긋나지만 실무엔 거의 안 쓰입니다.
- FILETIME 과 .NET Ticks 에 왜 BigInt 를 쓰나요?
- FILETIME 은 1601-01-01 UTC 부터 100 나노초 단위. 2100 년경 시점은 ~1.6 × 10¹⁷ ─ Number.MAX_SAFE_INTEGER(~9 × 10¹⁵) 를 한참 초과. 일반 JavaScript Number 로 저장하면 하위 자리가 소리 없이 어긋남. .NET ticks 도 마찬가지(2100 년경 ~6.6 × 10¹⁷). BigInt 는 JavaScript 의 임의 정밀도 정수 ─ 모든 자리수를 정확히 보존 ─ 그래서 FILETIME 을 이 도구로 왕복해도 정확히 같은 자리수가 나옵니다.
- Y2038 문제란 무엇이고 이 도구의 Unix 출력에도 영향이 있나요?
- 많은 레거시 C 프로그램이 Unix 시간을 부호 있는 32 비트 정수로 저장 ─ 2³¹ − 1 초 후인 2038-01-19 03:14:07 UTC 에 오버플로. 이 도구는 시간을 JavaScript 밀리초(64 비트 부동소수점, 1970 기준 ±285 614 년 유효) 로 저장하므로 Y2038 은 문제 없습니다. 프리셋으로 Y2038 을 노출해 각 형식이 그 순간을 어떻게 표현하는지 볼 수 있습니다. NTP 는 32 비트 초 카운터가 재시작되는 2036 년 자체 롤오버가 있고, 그것도 프리셋입니다.
- 왜 Excel 1900 과 Excel 1904 둘 다 노출하나요?
- Excel for Windows 는 1900 을 기준으로 쓰고, Excel for Mac(과 최근까지 Numbers) 는 1904 를 씁니다. Windows 분석가와 Mac 분석가가 스프레드시트를 주고받으면 각 앱에서는 옳게 보이지만 시리얼 숫자를 그대로 복사하면 ~4 년 어긋납니다. 두 형식을 모두 노출해 감지/변환할 수 있게 합니다.