Universal Epoch Converter
Different platforms count from different starting points. Unix counts seconds from 1970; Windows FILETIME counts 100-ns ticks from 1601; .NET from 0001; Excel from 1899-12-30. This converter takes a value in any system and emits the equivalent in all seven major epoch conventions.
Quick Conversion
Formula: .NET ticks = (unix_sec × 1000 + 62135596800000) × 10000
Epoch system reference
| System | Epoch | Unit | Used by |
|---|---|---|---|
| Unix (POSIX) | 1970-01-01T00:00:00Z | seconds | The standard. Ken Thompson, 1971. Used by Linux, macOS, JSON APIs. |
| JavaScript / Java | 1970-01-01T00:00:00Z | milliseconds | Date.now() in JS, System.currentTimeMillis() in Java. ms-precision. |
| Windows FILETIME | 1601-01-01T00:00:00Z | 100-ns ticks | Introduced with Windows NT 3.1 (1993). 100-ns resolution from 1601. |
| .NET DateTime.Ticks | 0001-01-01T00:00:00Z | 100-ns ticks | Microsoft .NET — 100-ns ticks from 0001-01-01 (Gregorian extrapolation). |
| Mac OS Classic | 1904-01-01T00:00:00Z | seconds | Classic Mac OS (pre OS X) — seconds from 1904. Used by HFS file metadata. |
| Excel serial date | 1899-12-30T00:00:00Z | days | Excel days from 1899-12-30 (the famous 1900-leap-year bug shifts it from Jan 1). |
| GPS time | 1980-01-06T00:00:00Z | seconds | GPS Time epoch (1980-01-06) — no leap seconds, drifts +18s vs UTC by 2024. |
Need just the Unix epoch? Live Unix timestamp.
Cross-epoch math
Windows FILETIME ↔ Unix seconds:
unix_sec = (filetime_ticks - 116444736000000000) / 10000000
.NET DateTime.Ticks ↔ Unix ms:
unix_ms = (ticks - 621355968000000000) / 10000
Excel serial ↔ Unix ms:
unix_ms = (excel_serial - 25569) * 86400000
GPS time ↔ Unix:
unix_sec = gps_sec + 315964800 ; ignores 18s leap driftWorked: FILETIME 133621992000000000 → (- 116444736000000000) = 17177256000000000 / 10000000 = 1717725600 sec = 2024-06-07T01:20:00Z.
How to convert between epoch systems
- 1Pick the SOURCE system from the dropdown (Unix, Windows FILETIME, .NET, Mac, Excel, GPS, or JS ms).
- 2Paste the raw integer (or decimal for Excel days) into the value field.
- 3All seven equivalent representations appear in the right rail — copy whichever your downstream consumer expects.
- 4Cross-check against the unified ISO 8601 line in the violet card; that's your sanity anchor.
- 5Save the snapshot to local history; click it later to re-load the source + value pair.
Seven epochs, one timeline — why every platform invented its own zero
In 2026 a data engineer ingesting a legacy Active Directory dump alongside Snowflake's Unix-epoch event log needs to reconcile 133621992000000000 with 1717725600 — and realise both refer to the same moment. The first is Windows FILETIME (100-ns ticks since 1601), the second is Unix seconds. This converter is the bridge.
The story starts at Bell Labs in 1969. Ken Thompson and Dennis Ritchie picked 1970-01-01T00:00:00 GMT as the UNIX epoch — a recent Thursday and easy to type. POSIX.1-1990 codified it. 1 second resolution, signed integer (32-bit until 2038, now 64-bit everywhere).
Microsoft Windows NT 3.1 (1993) needed sub-microsecond resolution for the security subsystem. Mark Lucovsky and David Cutler picked 1601-01-01T00:00:00Z — start of the 400-year Gregorian cycle — and 100-nanosecond ticks. Result: 64-bit FILETIME range from 1601 to 30,828 CE. Active Directory's lastLogonTimestamp, NTFS file metadata, and Win32 APIs all use FILETIME.
.NET arrived in 2002. Microsoft chose 0001-01-01T00:00:00Z as DateTime's zero, using 100-nanosecond ticks on a 64-bit signed integer. Range: 0001 to 9999 CE. Conversion to Unix ms requires subtracting 621,355,968,000,000,000 ticks and dividing by 10,000.
Apple's classic Mac OS (1984-2001) counted seconds from 1904-01-01. macOS X switched to Unix epoch in 2001, but HFS file metadata still uses the 1904 anchor. The gap: 2,082,844,800 seconds between Mac and Unix epochs.
Microsoft Excel — perversely — counts days from 1899-12-30, not 1900-01-01. This is because Lotus 1-2-3 wrongly treated 1900 as a leap year (it isn't — divisible by 100, not 400), and Excel preserved compatibility by inserting a fictional 1900-02-29. The effective epoch slipped to 1899-12-30. Day 1 still renders as 1900-01-01 in the UI.
GPS time has its own epoch: 1980-01-06T00:00:00 UTC. Unlike UTC, GPS does NOT insert leap seconds — so GPS time is currently 18 seconds ahead of UTC (as of 2024). High-precision GNSS receivers report both. NTP time uses 1900-01-01T00:00:00 UTC, with a 32-bit-seconds + 32-bit-fraction format that wraps every 136 years (next wrap: 2036-02-07). NTP4 (2010) added a 128-bit form.
The summary: every platform invented its own zero. This converter normalises all seven through a single ms pivot — copy whatever your downstream needs. For finer-grained ISO 8601 rewriting, see our ISO 8601 converter.
Trusted by DBAs, backend engineers, SREs and analysts
“I deal with FILETIME columns from a legacy MSSQL system and Unix epoch from Postgres. This converter bridges both in one place.”
“GPS time + Excel serial + .NET Ticks side-by-side is exactly what I need for cross-system reconciliation.”
“Caught an off-by-365-day bug in our Excel export thanks to seeing the 1899-12-30 epoch explanation.”
“Mac OS Classic timestamps from old HFS scans now make sense. The 1904 epoch explanation is gold.”
Love using our calculator?
Related developer tools
Related Articles
Dive deeper with our expert guides and tutorials related to Universal Epoch Converter