에포크 변환기: 유닉스 타임스탬프 ↔ 날짜

타임스탬프나 날짜를 붙여넣으면 내 시간대와 UTC 날짜는 물론, 그 숫자의 다른 해석도 모두 보여 줍니다.

s · ms · µs · ns · FILETIME · .NET · Excel · NTP · GPS · 브라우저에서 실행

예시 · 817876800

토요일

1995년 12월 2일

04:00:00 UTC

UTC
1995년 12월 2일 (토) · 04:00:00
1995년 12월 2일 (토) · 04:00:00UTC · UTC+00:00
상대 시간
31년 전
표기 형식
ISO 8601 · UTC
1995-12-02T04:00:00Z
ISO 8601 · UTC
1995-12-02T04:00:00Z
RFC 5322 · 이메일RFC 2822가 정의한 형식
Sat, 02 Dec 1995 04:00:00 +0000
HTTP 날짜RFC 9110
Sat, 02 Dec 1995 04:00:00 GMT
SQL DATETIMEUTC
1995-12-02 04:00:00
초
817876800
밀리초
817876800000
마이크로초
817876800000000
나노초
817876800000000000

숫자 하나 · 모든 에포크

실제 날짜가 되는 방식 7개

길이(9자리)를 보고 Unix 초 기준으로 읽었습니다. GPS 초 기준으로 읽으면 2005년 12월 6일입니다. 이 역시 실제 날짜이므로 클릭 한 번으로 바꿀 수 있게 둡니다.

읽는 방식날짜
1900–2100년: 실제 날짜오늘2038년: 32비트 한계실제 날짜가 아님행을 고르면 그 방식으로 읽습니다
현재 시각

밀리초
마이크로초
나노초
ISO 8601

브라우저 시계는 밀리초 단위로만 셉니다. 그 뒤의 0은 자릿수를 채운 것이지 정밀도가 아닙니다.

날짜·시간 → 타임스탬프
시간대

UTC · 이 날짜 기준 UTC+00:00

1793813880
밀리초
1793813880000
ISO 8601
2026-11-04T17:38:00Z
시작과 끝(UTC)
시작끝
일17937504001793836799
월17934912001796083199
연17672256001798761599

모든 처리는 이 탭 안에서 이루어지며, 붙여넣은 내용은 어디에도 전송되지 않습니다.

타임스탬프 변환기 사용법

가진 타임스탬프를 단위와 상관없이 입력란에 붙여넣으면 내 시간대와 UTC 날짜가 나타납니다. 날짜, 이메일 Date 헤더, 지금(now)이라는 단어를 입력해 에포크 시간을 얻을 수도 있습니다.

이 페이지는 숫자를 초, 밀리초, 마이크로초, 나노초로 한꺼번에 읽어 실제 날짜가 되는 방식을 고르고, 그 이유를 말하며, 다른 방식도 클릭 한 번 거리에 둡니다. 답 아래에서는 같은 숫자를 Windows, .NET, Mac, Excel, NTP, GPS 타임스탬프로도 읽고, 모든 형식을 복사할 수 있습니다.

에포크 변환기가 133756272000000000을 Windows FILETIME으로 읽어 2024년 11월 9일로 표시하고, 모든 에포크를 한 시간축에 보여 주는 화면에포크 변환기가 133756272000000000을 Windows FILETIME으로 읽어 2024년 11월 9일로 표시하고, 모든 에포크를 한 시간축에 보여 주는 화면무엇이든 붙여넣기어떤 단위의 숫자든, ISO 날짜, 이메일 Date 헤더, SQL 날짜 시간, ‘지금’(now)이라는 단어까지. 방향 표시가 어떻게 읽었는지 알려 줍니다.자릿수 세기숫자 아래의 눈금이 자릿수를 세 개씩 묶어 주므로 18자리는 여섯 묶음으로 읽힙니다. 무엇인지 알아내는 첫 단서입니다.답부터 먼저요일과 날짜, 이어서 UTC와 내 시간대의 시각, 그리고 복사할 수 있는 모든 형식을 보여 줍니다.어떤 방식으로, 왜어떤 방식으로 읽었고 왜 그렇게 골랐는지 말로 설명하고, 실제 날짜가 되는 다른 방식도 알려 줍니다.다른 모든 에포크같은 숫자를 모든 단위와 에포크로 읽어 각각의 시작점에서 뻗은 막대로 보여 줍니다. 행을 고르면 그 방식으로 읽습니다.
Windows FILETIME을 읽는 화면입니다. 번호를 선택하면 각 부분이 하는 일을 볼 수 있습니다.

에포크 시간이란 무엇이며, 왜 1970년부터 시작하나요?

에포크 시간, 또는 유닉스 시간은 POSIX가 ‘에포크(the Epoch)’라고 부르는 순간인 1970-01-01 00:00:00 UTC부터 지난 초의 수입니다. 타임스탬프 0이 바로 그 순간이고, 817876800은 1995-12-02 04:00 UTC입니다.

1970년을 고른 이유를 기록한 1차 자료는 없습니다. 1971년 11월의 첫 Unix 매뉴얼은 1971년 1월 1일부터 60분의 1초를 셌고, 그 시계가 약 2년 반이면 다 찬다고 적었습니다. 1979년 7판에 이르러서는 1970년 1월 1일부터의 초를 세게 되었는데, Unix가 만들어지던 무렵에 가까운 딱 떨어지는 날짜입니다. UTC 자체는 1972년에야 시작되었으므로, 그 이전의 타임스탬프는 관례상 UTC입니다.

Unix 1판, 1971년1971년 1월 1일부터의 60분의 1초, 32비트

1973년 4월 8일에 가득 참 · 2.27년

Unix 7판, 1979년1970년 1월 1일부터의 초, 부호 있는 32비트 수

1901-12-13 → 2038-01-19양쪽으로 각각 68년

음수 값: 1970년 이전

연대--지향적인 사용자라면 2**32개의 60분의 1초가 약 2.5년에 불과하다는 것을 알아챌 것이다.

UNIX Programmer's Manual 1판, time (II), 1971년 11월 3일

이 페이지가 읽는 모든 에포크를 한 줄에

  1. .NET0001-01-01 · 100ns 틱
  2. Windows FILETIME1601-01-01 · 100ns 틱
  3. Excel1899-12-30 · 일
  4. NTP1900-01-01 · 초
  5. Mac HFS+1904-01-01 · 초
  6. Excel 19041904-01-01 · 일
  7. Unix1970-01-01 · 초
  8. GPS1980-01-06 · 초
두 막대 모두 카운터의 크기로 계산했습니다. 2³²개의 60분의 1초는 2.27년 만에 가득 차며, 매뉴얼 자체의 추정보다 조금 짧습니다. 이 페이지가 읽는 다른 에포크도 모두 같은 줄의 다른 지점에서 시작하며, 변환기 자체의 시간축으로 그렸습니다. 출처: time (II), 1971, time (2), 1979

내 타임스탬프는 초, 밀리초, 마이크로초, 나노초 중 무엇인가요?

자릿수를 세어 보세요. 현재 타임스탬프는 초 단위면 10자리, 밀리초면 13자리, 마이크로초면 16자리, 나노초면 19자리입니다. JavaScript와 Java는 밀리초를, Unix 도구와 대부분의 API는 초를 씁니다.

자릿수는 강력한 단서이지만 증거는 아닙니다. NTP, GPS, Mac 타임스탬프도 현재 10자리이고, Windows FILETIME과 .NET 틱 수는 둘 다 18자리입니다. 그래서 이 페이지는 모든 척도를 한꺼번에 읽고, 고른 방식을 다른 방식들 옆에 보여 줍니다. 또 FILETIME은 JavaScript가 정확히 담을 수 있는 크기를 넘으므로, 이 페이지는 붙여넣은 숫자를 그대로 유지합니다.

10자리 · 척도 4개 · 숫자만으로는 어느 것인지 알 수 없습니다

Unix 초1792972800
NTP 초4001961600
GPS 초1477008018
Mac HFS+3875817600
Unix 밀리초1792972800000
Unix 마이크로초1792972800000000

18자리 · 척도 2개 · 첫 자리만으로 구별됩니다

Windows FILETIME134374464000000000
.NET 틱639285696000000000
Unix 나노초1792972800000000000

10자리 초 값은 2001-09-09T01:46:40Z부터 2286-11-20T17:46:39Z까지입니다. 이는 285년에 걸친 범위이지 단위가 아닙니다.

모든 값은 같은 순간(2026년 10월 26일 00:00 UTC)을 각자의 척도로 나타낸 것입니다. 길이로 Unix 단위는 구별되지만 에포크는 구별되지 않습니다. 출처: ECMA-262 §21.4.1, [MS-DTYP] 2.3.3, DateTime.Ticks

유닉스 타임스탬프를 내 시간대의 날짜로 변환하려면?

유닉스 타임스탬프에는 시간대가 없으며, 어디서나 같은 한 순간을 가리킵니다. 날짜는 어디서 읽느냐에 따라 달라지므로, 이 페이지는 내 시간대와 UTC를 나란히 보여 주고, 고른 다른 시간대로도 보여 줍니다.

시간대 선택기는 운영체제가 쓰는 것과 같은 IANA 시간대 데이터베이스를 사용하므로, 일광 절약 시간(서머타임) 변경은 오늘이 아니라 그 날짜 기준으로 적용됩니다. 반대 방향에서는 오프셋 없이 입력한 날짜를 UTC로 읽고, 내 시간대로 다시 읽도록 제안합니다.

한 순간1793057400= 2026-10-26T23:30:00Z

  • 로스앤젤레스16:3010월 26일 (월)UTC−07:00
  • 뉴욕19:3010월 26일 (월)UTC−04:00
  • UTC23:3010월 26일 (월)UTC+00:00
  • 베를린00:3010월 27일 (화)UTC+01:00
  • 콜카타05:0010월 27일 (화)UTC+05:30
  • 도쿄08:3010월 27일 (화)UTC+09:00
  • 로드하우섬10:3010월 27일 (화)UTC+11:00

베를린, 2026년 3월 29일23시간 · 시계가 02:00에서 03:00 시각으로 건너뜀

베를린, 2026년 10월 25일25시간 · 시계가 03:00에서 02:00 시각으로 되돌아감

중부유럽 표준시 · UTC+01:00중부유럽 하계 표준시 · UTC+02:00두 번 있었던 1시간없었던 1시간

타임스탬프 하나, 현지 시계 7개: 현지 날짜가 UTC와 다른 곳에는 표시를 했습니다. 2026년 베를린의 두 번의 전환일에는 어떤 순간도 가리키지 않는 시각과, 두 순간을 가리키는 시각이 있었습니다. 출처: ECMA-262 §21.4.1.19, IANA tz

2038년에 유닉스 시간은 어떻게 되나요?

부호 있는 32비트 정수로 저장한 유닉스 시간은 2147483647에서 끝나며, 이는 2038-01-19 03:14:07 UTC입니다. 1초 뒤에는 1901년 12월의 날짜로 되돌아갑니다. POSIX가 이제 요구하는 대로 64비트로 세는 시스템은 영향을 받지 않습니다.

2026년의 위험은 시계가 아니라 저장소에 있습니다. MySQL의 TIMESTAMP 열은 여전히 2038-01-19 03:14:07 UTC에 끝나며, 32비트 필드를 유지한 파일 형식이나 임베디드 기기도 마찬가지입니다. NTP에는 그보다 이른 자체 롤오버가 있어, 32비트 초가 2036년에 한 바퀴 돕니다. 이 페이지는 2038년 경계에 가깝거나 넘은 타임스탬프를 표시해 줍니다.

2,147,483,647부호 있는 32비트의 가장 큰 수

01111111 11111111 11111111 11111111

2038년 1월 19일 (화)03:14:07 UTC

+ 1초

-2,147,483,648같은 32비트를 부호 있는 수로 읽은 값

10000000 00000000 00000000 00000000

1901년 12월 13일 (금)20:45:52 UTC

마지막 1초(UTC)

부호 있는 32비트 time_t2038-01-19 03:14:07
부호 없는 32비트 초2106-02-07 06:28:15
MySQL TIMESTAMP 열2038-01-19 03:14:07
NTP, era 02036-02-07 06:28:15
Mac HFS+ 날짜2040-02-06 06:28:15

오늘2038-01-19

모든 끝은 필드 자체의 크기로 계산한, 담을 수 있는 마지막 1초입니다. POSIX.1-2024가 요구하는 64비트 time_t는 1970년 앞뒤로 약 2923억년까지 닿습니다. 출처: POSIX.1-2024 A.4.19, MySQL 8.4, RFC 5905 §6, TN1150

유닉스 타임스탬프가 음수일 수 있나요?

네. 음수 타임스탬프는 1970년 이전의 날짜입니다. -1은 1969-12-31 23:59:59 UTC이고, -86400은 1969-12-31 00:00:00 UTC입니다.

POSIX 자체는 음수 값을 정의하지 않지만, GNU와 대부분의 시스템은 문서화된 확장으로 이를 1970년 이전 날짜로 다루며, JavaScript, Python, PostgreSQL도 마찬가지입니다. 예외는 MySQL로, TIMESTAMP 열은 1970년에 시작하고 FROM_UNIXTIME(-1)은 NULL을 반환합니다. 생년월일과 역사 기록은 평범한 음수 타임스탬프이므로, 이 페이지는 이를 오류로 보지 않고 날짜로 읽습니다.

초거슬러 간 거리(로그 척도)날짜(UTC)

01970년 1월 1일 (목)00:00:00 UTC
-11969년 12월 31일 (수)23:59:59 UTC
-86,4001969년 12월 31일 (수)00:00:00 UTC
-31,536,0001969년 1월 1일 (수)00:00:00 UTC
-1,000,000,0001938년 4월 24일 (일)22:13:20 UTC
-2,147,483,6481901년 12월 13일 (금)20:45:52 UTC
  • POSIX연도가 <1970이거나 값이 음수이면, 그 관계는 정의되지 않는다.
  • GNU date@-1은 1969-12-31 23:59:59 UTC: POSIX에 대한 확장으로서의 음수 값
  • JavaScript1970년 앞뒤로 약 273,790년 이내의 모든 날짜
  • MySQL TIMESTAMP1970-01-01 00:00:01 UTC에 시작: 음수 값을 담을 수 없음
각 값을 Unix 초로 읽었습니다. 막대는 로그 척도라서 작은 값도 보입니다. 마지막 행은 부호 있는 32비트 필드가 담는 가장 작은 수로, 2038년 문제의 반대쪽 끝입니다. 출처: POSIX.1-2024 §4.19, GNU Coreutils, ECMA-262 §21.4.1, MySQL 8.4

Windows, .NET, Mac, Excel, NTP, GPS: 다른 에포크들

많은 시스템이 저마다의 0부터 셉니다. Windows는 1601년, .NET은 서기 1년, Mac과 HFS+는 1904년, Excel은 1900년, NTP는 1900년, GPS는 1980년 1월 6일부터입니다. 유닉스 타임스탬프로는 말이 안 되는 숫자는 대개 이 중 하나입니다.

예를 들어 FILETIME 133756272000000000은 1601년부터의 100나노초 간격을 센 값으로, 2024-11-09 12:00:00 UTC입니다. Excel은 일수를 세며 1900년을 일부러 윤년으로 취급하므로, 61 미만의 일련 번호는 하루가 어긋나고 이 페이지는 이를 표시합니다. GPS 시간은 윤초를 건너뛰며 2017년부터 UTC보다 18초 앞서 있습니다.

에포크단위시작2026년 10월 26일 기준자릿수시간대쓰이는 곳
Unix 초초1970-01-01179297280010UTC(POSIX)date +%s, Python의 time.time()
Unix 밀리초밀리초1970-01-01179297280000013UTCJavaScript의 Date.now(), Java
Unix 나노초나노초1970-01-01179297280000000000019UTCGo의 UnixNano()
Windows FILETIME100ns 틱1601-01-0113437446400000000018UTC(FAT에서는 현지 시각)NTFS, Active Directory의 lastLogon, Win32
.NET 틱100ns 틱0001-01-0163928569600000000018Kind에 따라 UTC 또는 현지 시각.NET의 DateTime.Ticks
Excel 일련 번호일1899-12-30463215없음: 시계 시각Excel, Google Sheets, LibreOffice
Excel 1904일1904-01-01448595없음: 시계 시각구형 Mac용 Excel
Mac HFS+초1904-01-01387581760010GMT(기존 HFS: 현지 시각)HFS+ 파일 날짜
NTP 초초1900-01-01400196160010UTCNTP 패킷
GPS 초초1980-01-06147700801810윤초 없음: UTC + 18초GPS 수신기, RINEX 파일
모든 값은 같은 순간(2026년 10월 26일 00:00 UTC)을 각자의 척도로 나타낸 것이며, 이 페이지가 쓰는 엔진으로 계산했습니다. Google Sheets와 LibreOffice도 1899-12-30부터 일수를 세므로, 1900년 3월 1일부터는 일련 번호가 Excel과 같습니다. 출처: [MS-DTYP] 2.3.3, DateTime.Ticks, Excel, Google Sheets, LibreOffice, TN1150, RFC 5905, RINEX 3.05

유닉스 시간은 윤초를 세나요?

아니요. 유닉스 시간은 하루를 언제나 정확히 86,400초로 두므로 윤초에는 고유한 숫자가 없으며, POSIX도 그렇게 밝힙니다. 분해된 POSIX 시간은 겉보기와 달리 반드시 UTC인 것은 아닙니다.

1972년 이후 UTC에는 윤초가 27번 추가되었습니다. 유닉스 시간에는 그 추가된 1초에 해당하는 숫자가 없어서 타임스탬프 하나가 2초를 나타냅니다. 마지막 윤초는 2016-12-31에 있었고, 2022년 국제도량형총회는 윤초가 필요해지는 한계를 2035년까지 늘리기로 결정했으며, 이는 사실상 윤초를 끝내는 것입니다. 윤초가 처음부터 없었던 GPS 시간이 그 차이를 보여 줍니다. GPS 시간은 18초 앞서 있습니다.

1998년 12월 31일의 마지막 몇 초

UTC23:59:5823:59:5923:59:6000:00:0000:00:01
Unix 시간915148798915148799915148800915148800915148801
GPS 시간599184010599184011599184012599184013599184014

Unix 시간은 915148800 값을 두 번 씁니다. 윤초가 없는 GPS 시간은 계속 셉니다.

윤초 27회2016년 12월 31일 뒤로는 없음 · 2027년 6월 28일 이전 예정 없음

GPS 시간 시작 전GPS 시간 시작 후: 하나가 추가될 때마다 GPS 시간이 1초씩 더 앞섬

협정 세계시(UTC)에는 윤초가 포함된다. 그러나 POSIX 시간(에포크 이후의 초)에서는 시간 차이를 쉽고 호환성 있게 계산하는 방법을 제공하기 위해 윤초를 무시한다(적용하지 않는다). 따라서 분해된 POSIX 시간은 겉보기와 달리 반드시 UTC인 것은 아니다.

POSIX.1-2024, Rationale A.4.19
이 윤초 직후 GPS 시간은 UTC보다 13초 앞서 있었습니다. 출처: POSIX.1-2024 A.4.19, leap-seconds.list, RINEX 3.05

Python, JavaScript, Java, C#, Go, SQL, 셸에서 유닉스 타임스탬프 변환

어느 언어든 한두 줄이면 양방향으로 변환합니다. 함정은 단위(JavaScript와 Java는 밀리초로 셈)와 시간대(데이터베이스는 세션 시간대로 값을 읽을 수 있음)입니다.

아래 예제는 모두 817876800을 날짜로, 날짜를 다시 초로 바꾸며, 각각 실행해 출력을 확인했습니다. 셸에서 macOS와 BSD 계열은 date -r 817876800을, GNU/Linux는 date -d @817876800을 씁니다. 둘은 서로 바꿔 쓸 수 없습니다.

from datetime import datetime, timezone

t = datetime.fromtimestamp(817876800, tz=timezone.utc)
print(t.isoformat())  # 1995-12-02T04:00:00+00:00

back = datetime(1995, 12, 2, 4, 0, tzinfo=timezone.utc)
print(int(back.timestamp()))  # 817876800

2026년 10월 26일에 Python 3.14.4 환경에서 실행: 주석에 적힌 그대로 출력합니다.

각 탭은 붙여넣은 그대로 실행되는 완전한 프로그램 또는 세션입니다. 셸 탭에서는 사용하는 시스템에 맞는 절반을 실행하세요. 출처: docs.python.org, ECMA-262, Instant, DateTimeOffset, pkg.go.dev/time, PostgreSQL, MySQL, date(1), GNU Coreutils

에포크 시간: 자주 묻는 질문

에포크 시간이란 무엇인가요?

에포크 시간(유닉스 시간, 유닉스 타임스탬프)은 1970-01-01 00:00:00 UTC부터 지난 초의 수이며, 윤초는 세지 않습니다. 숫자 하나는 비교, 정렬, 전송이 쉬워서 컴퓨터는 날짜를 이렇게 저장합니다. 타임스탬프 1000000000은 2001-09-09 01:46:40 UTC였고, 맨 위 입력란에서 어떤 값이든 날짜로 바꿀 수 있습니다.

에포크 시간을 날짜로 변환하는 방법은?

맨 위 입력란에 숫자를 붙여넣으세요. 이 페이지는 숫자를 초, 밀리초, 마이크로초, 나노초로 읽고, 실제 날짜가 되는 방식을 골라 내 시간대와 UTC로 날짜를 보여 줍니다. 직접 하려면 초에 1,000을 곱해 날짜 함수에 넘기면 됩니다. JavaScript라면 new Date(817876800 * 1000)입니다.

현재 에포크 시간은 어떻게 확인하나요?

이 페이지의 시계가 현재 유닉스 시간을 초, 밀리초, 마이크로초, 나노초로 실시간 표시하며, 각 값을 복사할 수 있습니다. 내 기기의 시계에서 가져오므로 정확도는 그 시계만큼입니다. 인터넷으로 시간을 동기화하는 컴퓨터라면 보통 오차가 1초 미만입니다. 명령줄에서는 date +%s가 초 단위로 출력합니다.

유닉스 타임스탬프는 초인가요, 밀리초인가요?

전통적인 유닉스 타임스탬프는 초 단위지만 JavaScript, Java, 많은 웹 API는 밀리초를 쓰고, 일부 데이터베이스와 로그는 마이크로초나 나노초를 씁니다. 현재 타임스탬프는 초 단위면 10자리, 밀리초면 13자리입니다. 날짜가 1970년이나 수천 년 뒤로 나오면 단위가 틀린 것입니다. 이 페이지는 모든 단위를 시도해 말이 되는 것을 보여 줍니다.

유닉스 시간은 왜 1970년부터 시작하나요?

이유를 기록한 1차 자료는 없습니다. 1971년의 첫 Unix 매뉴얼은 1971년 1월 1일부터 60분의 1초를 셌고, 몇 년 안에 다 찰 것으로 내다봤습니다. 단위가 초로 바뀌면서 1970년 1월 1일이 시작점이 되었습니다. Unix가 만들어지던 무렵에 가까운 딱 떨어지는 날짜로, 여기서부터 32비트 초는 2038년까지 닿습니다.

유닉스 시간은 UTC와 같나요?

거의 같지만 완전히 같지는 않습니다. 유닉스 시간은 UTC의 달력과 시계를 따르지만 하루를 언제나 정확히 86,400초로 두고 윤초를 무시하므로, 윤초에는 고유한 타임스탬프가 없습니다. POSIX 스스로도 분해된 유닉스 시간이 반드시 UTC는 아니라고 말합니다. 사람이 읽는 날짜와 시각에서는 차이가 드러나지 않지만, 윤초를 가로지르는 정밀한 간격에서는 드러납니다.

2038년 문제란 무엇인가요?

부호 있는 32비트 수로 저장한 유닉스 시간의 한계는 2147483647, 곧 2038-01-19 03:14:07 UTC입니다. 1초 뒤에는 넘쳐서 1901년 12월로 읽힙니다. 최신 운영체제는 64비트 시간을 써서 안전하지만, 일부 데이터베이스, 파일 형식, 임베디드 기기에는 32비트 필드가 남아 있습니다. 예컨대 MySQL의 TIMESTAMP 열은 여전히 그 초에 끝납니다.

1970년 이전 날짜도 변환할 수 있나요?

네. 1970년 이전 날짜는 음수 타임스탬프로, -1은 1969-12-31 23:59:59 UTC, 1950년의 날짜는 약 -6억 3,100만입니다. 음수를 붙여넣으면 날짜를, 오래된 날짜를 입력하면 음수 값을 보여 줍니다. 엄격한 POSIX는 음수 값을 정의하지 않고 MySQL의 TIMESTAMP는 이를 담지 못하지만, 대부분의 언어와 데이터베이스는 1970년 이전 날짜로 읽습니다.

Windows FILETIME을 날짜로 변환하려면?

FILETIME은 1601-01-01 UTC부터 100나노초 간격을 세므로 현재 18자리입니다. 입력란에 붙여넣으면 이 페이지가 Unix 단위들과 함께 FILETIME으로 읽습니다. 133756272000000000은 2024-11-09 12:00:00 UTC입니다. 직접 하려면 116444736000000000을 빼고 10,000,000으로 나누면 Unix 초가 됩니다.

Excel 날짜 일련 번호를 타임스탬프로 변환하려면?

Excel 일련 번호는 일수를 세고 시각은 소수로 나타냅니다. 기본 1900 날짜 체계에서 45658은 2025-01-01입니다. 붙여넣으면 1900과 1904 날짜 체계 모두로 Excel 날짜를 읽습니다. Excel은 1900년을 일부러 윤년으로 취급해 61 미만의 일련 번호는 하루가 어긋나며, 이 페이지는 추측하지 않고 이를 표시합니다.

변환기가 시간대와 일광 절약 시간을 처리하나요?

네. 각 날짜를 내 시간대와 UTC로 보여 주며, America/New_York, Asia/Kolkata 등 어떤 IANA 시간대든 고를 수 있습니다. 일광 절약 시간은 오늘이 아니라 변환하는 날짜 기준이라, 여름 타임스탬프는 겨울에 봐도 여름 시간으로 나옵니다. 오프셋 없이 입력한 날짜는 UTC로 읽으며, 클릭 한 번이면 내 시간대로 다시 읽습니다.

내 타임스탬프가 어딘가로 전송되나요?

아니요. 변환은 브라우저에서 이루어지므로 붙여넣은 내용은 기기를 떠나지 않으며 어떤 서버도 보지 못합니다. ‘링크 복사’로 만든 링크는 주소에 타임스탬프를 담고 있어, 그 링크로 연 페이지에 날짜가 바로 나타납니다. 그 밖에는 아무것도 저장하거나 전송하지 않습니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기