Timestamp & Epoch Converter — Ticks, FILETIME, Excel Serial

Q: How do I convert .NET DateTime ticks to a date?

Call /api/epoch/convert?from=ticks&value=638000000000000000. Ticks are 100-nanosecond intervals since 0001-01-01, so the offset to the Unix epoch is exactly 621355968000000000 ticks — subtract it, then divide by 10,000,000 for Unix seconds.

Q: Why do I have to tell the API which format my number is in?

Because 1751000000 is a valid Unix seconds value (2025) and a valid Unix milliseconds value (1970), and no cutoff heuristic can tell them apart safely. from is required and there is no auto-detection.

REAL DATA

Convert one instant between Unix s/ms/µs/ns, ISO 8601, Windows FILETIME, .NET ticks, Excel serials, Cocoa, HFS+, NTP and Julian Day — exactly.

Authoritative reference data or standards computation

Base URL: /api/epoch
Category: Date & Time
Capabilities: 2 routes
Last updated: July 29, 2026

Data source: Primary epoch specifications (POSIX.1-2024 §4.19, RFC 3339, RFC 5905, Microsoft FILETIME & .NET ticks, Excel date systems, Apple NSDate & TN1150, USNO Julian date) — each cited per row at /api/epoch

GET /api/epoch Every supported epoch with its origin, unit, resolution and range Returns a list

The reference table behind /convert: what each representation counts, from when, how finely, how far, and which specification defines it.

Live requestRuns against the public API

No key required

GET/api/epoch

Request parameters

search

Case-insensitive substring filter over `id`, `name`, `typicalSource` and `note` — e.g. `excel`, `windows`, `mac`. Searching a lookalike format (`webkit`, `postgres`, `radius`, `date(`) finds the row whose note explains why it is not that format. No match returns an empty list plus a warning, never a fallback row.

Advanced response options6 options

countdefault all matches

Limit the number of returned records (1–100). Defaults to all matches.

fields

Return only these fields (comma-separated). Mutually exclusive with 'exclude'.

exclude

Return all fields except these (comma-separated).

formatdefault json

Response format: json envelope, ndjson (one record per line) or csv.

prettydefault false

Pretty-print the JSON response.

unwrapdefault false

Drop the envelope: return the raw array/object without data/meta wrapper.

Response

Example parameters are ready. Send the request to inspect the live response.

Route reference

Code, request parameters, response fields and verified examples 7 params · 12 fields · 4 examples

Code samples Ready-to-copy requests in 4 languages

curl JavaScript Python PHP

curl "https://randomapi.dev/api/epoch"

const res = await fetch("https://randomapi.dev/api/epoch");
const { data, meta } = await res.json();

import requests

data = requests.get("https://randomapi.dev/api/epoch").json()["data"]

$json = json_decode(file_get_contents(
  "https://randomapi.dev/api/epoch"
), true);
$data = $json["data"];

Parameters Route-specific request inputs 1

Parameter	Type	Default & allowed	Description
`search`	string	allowed: 1 – 60 example: excel	Case-insensitive substring filter over `id`, `name`, `typicalSource` and `note` — e.g. `excel`, `windows`, `mac`. Searching a lookalike format (`webkit`, `postgres`, `radius`, `date(`) finds the row whose note explains why it is not that format. No match returns an empty list plus a warning, never a fallback row.

search string

allowed: 1 – 60

example: search=excel

Universal parameters Shared response and formatting options 6

Parameter	Type	Default & allowed	Description
`count`	int	default: all matches allowed: 1 – 100 example: 3	Limit the number of returned records (1–100). Defaults to all matches.
`fields`	list	example: id,name	Return only these fields (comma-separated). Mutually exclusive with 'exclude'.
`exclude`	list	example: note	Return all fields except these (comma-separated).
`format`	enum	default: json allowed: json \| ndjson \| csv example: csv	Response format: json envelope, ndjson (one record per line) or csv.
`pretty`	boolean	default: false example: true	Pretty-print the JSON response.
`unwrap`	boolean	default: false example: true	Drop the envelope: return the raw array/object without data/meta wrapper.

count int

Limit the number of returned records (1–100). Defaults to all matches.

default: all matches

allowed: 1 – 100

example: count=3

fields list

Return only these fields (comma-separated). Mutually exclusive with 'exclude'.

example: fields=id,name

exclude list

Return all fields except these (comma-separated).

example: exclude=note

format enum

Response format: json envelope, ndjson (one record per line) or csv.

default: json

allowed: json | ndjson | csv

example: format=csv

pretty boolean

Pretty-print the JSON response.

default: false

example: pretty=true

unwrap boolean

Drop the envelope: return the raw array/object without data/meta wrapper.

default: false

example: unwrap=true

Response schema Fields returned in each record 12

Field	Type	Description	Example
`id`	string	Value accepted by /convert's `from` parameter.	filetime
`name`	string	Human name of the representation.	Windows FILETIME
`origin` nullable	string (ISO 8601)	The instant at which the value is zero, in UTC. Years outside 0000–9999 use the ISO 8601 expanded ±YYYYYY form. Null for `iso`, which is a calendar rendering rather than a counter. `origin` + `minValue` units equals the start of `range` on every row but `excel`: the 1900 date system has two anchors and serials 1–59 sit one day later than the origin shown — that row's `note` spells both out.	1601-01-01T00:00:00.000000000Z
`unit`	string	What one unit of the value counts.	100-nanosecond interval
`resolution`	string	Smallest step the representation distinguishes, plus any storage caveat.	100 ns
`minValue`	string	Lowest value /convert accepts for this representation.	0
`maxValue`	string	Highest value /convert accepts for this representation.	18446744073709551615
`range`	string	The instants those bounds correspond to, written start … end. Where a format has no native bound, this is the API's own instant limit instead.	1601-01-01T00:00:00.000000000Z … +060056-05-28T05:36:10.955161500Z
`typicalSource`	string	Systems that genuinely emit values in THIS representation — one of the columns `search` matches on. Formats that merely look similar live in `note` instead, never here.	Windows GetSystemTimeAsFileTime, NTFS $MFT records, Active Directory lastLogonTimestamp, ETW
`specification`	string	The primary document that defines this epoch.	Microsoft FILETIME structure (minwinbase.h)
`specificationUrl`	string (URL)	Link to that primary document.	https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime
`note`	string	The caveat that actually bites when using this representation.	An unsigned 64-bit count of 100-nanosecond intervals since 1601-01-01 (UTC). The Unix epoch is exactly 116444736000000000, the constant Microsoft's own time_t conversion sample adds.

id string

Value accepted by /convert's `from` parameter.

example: filetime

name string

Human name of the representation.

example: Windows FILETIME

origin string (ISO 8601) nullable

The instant at which the value is zero, in UTC. Years outside 0000–9999 use the ISO 8601 expanded ±YYYYYY form. Null for `iso`, which is a calendar rendering rather than a counter. `origin` + `minValue` units equals the start of `range` on every row but `excel`: the 1900 date system has two anchors and serials 1–59 sit one day later than the origin shown — that row's `note` spells both out.

example: 1601-01-01T00:00:00.000000000Z

unit string

What one unit of the value counts.

example: 100-nanosecond interval

resolution string

Smallest step the representation distinguishes, plus any storage caveat.

example: 100 ns

minValue string

Lowest value /convert accepts for this representation.

example: 0

maxValue string

Highest value /convert accepts for this representation.

example: 18446744073709551615

range string

The instants those bounds correspond to, written start … end. Where a format has no native bound, this is the API's own instant limit instead.

example: 1601-01-01T00:00:00.000000000Z … +060056-05-28T05:36:10.955161500Z

typicalSource string

Systems that genuinely emit values in THIS representation — one of the columns `search` matches on. Formats that merely look similar live in `note` instead, never here.

example: Windows GetSystemTimeAsFileTime, NTFS $MFT records, Active Directory lastLogonTimestamp, ETW

specification string

The primary document that defines this epoch.

example: Microsoft FILETIME structure (minwinbase.h)

specificationUrl string (URL)

Link to that primary document.

example: https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime

note string

The caveat that actually bites when using this representation.

example: An unsigned 64-bit count of 100-nanosecond intervals since 1601-01-01 (UTC). The Unix epoch is exactly 116444736000000000, the constant Microsoft's own time_t conversion sample adds.

Documented examples

Build-generated requests and complete responses 4

All thirteen epochs /api/epoch

GET /api/epoch

{
  "data": [
    {
      "id": "unix",
      "name": "Unix time (seconds)",
      "origin": "1970-01-01T00:00:00.000000000Z",
      "unit": "second",
      "resolution": "1 s (a decimal fraction is accepted and emitted)",
      "minValue": "-8640000000000",
      "maxValue": "8640000000000",
      "range": "-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z",
      "typicalSource": "POSIX time_t, date +%s, JWT iat/exp (RFC 7519 NumericDate), RADIUS Event-Timestamp (RFC 2869 §5.3), Stripe API created",
      "specification": "POSIX.1-2024 (Issue 8) §4.19 Seconds Since the Epoch",
      "specificationUrl": "https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19",
      "note": "POSIX accounts for every day as exactly 86400 seconds, so Unix time contains no leap seconds and neither does this endpoint. The count itself has no native bound; the range shown is this API's own instant limit."
    },
    {
      "id": "unixMs",
      "name": "Unix time (milliseconds)",
      "origin": "1970-01-01T00:00:00.000000000Z",
      "unit": "millisecond",
      "resolution": "1 ms (a decimal fraction is accepted and emitted)",
      "minValue": "-8640000000000000",
      "maxValue": "8640000000000000",
      "range": "-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z",
      "typicalSource": "JavaScript Date.now(), Java System.currentTimeMillis(), Kafka, MongoDB, Microsoft /Date(…)/ JSON",
      "specification": "POSIX epoch scaled by 1000 (a de-facto convention, not a POSIX unit)",
      "specificationUrl": "https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19",
      "note": "Same epoch as Unix seconds, ×1000. This is the pair that silently breaks: 1751000000 is a plausible seconds value AND a plausible milliseconds value, which is why `from` is required. Microsoft's /Date(700000+0500)/ JSON wire format counts in this unit too, despite the tick-shaped digits: the number is milliseconds since midnight 1970-01-01 GMT and the suffix only records the original local offset."
    },
    {
      "id": "unixUs",
      "name": "Unix time (microseconds)",
      "origin": "1970-01-01T00:00:00.000000000Z",
      "unit": "microsecond",
      "resolution": "1 µs (a decimal fraction is accepted and emitted)",
      "minValue": "-8640000000000000000",
      "maxValue": "8640000000000000000",
      "range": "-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z",
      "typicalSource": "systemd journal __REALTIME_TIMESTAMP, Parquet and Arrow TIMESTAMP_MICROS, Cassandra WRITETIME, date +%s%6N",
    …
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

Both Excel date systems /api/epoch?search=excel

GET /api/epoch?search=excel

{
  "data": [
    {
      "id": "excel",
      "name": "Excel serial (1900 date system)",
      "origin": "1899-12-30T00:00:00.000000000Z",
      "unit": "day",
      "resolution": "1 day, fractional (Excel stores serials as IEEE-754 doubles, ≈1 µs near today)",
      "minValue": "1",
      "maxValue": "2958465.999999999999988",
      "range": "1900-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z",
      "typicalSource": "Excel for Windows, .xlsx numeric date cells, CSV exports, Lotus 1-2-3",
      "specification": "Microsoft — Date systems in Excel",
      "specificationUrl": "https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487",
      "note": "Serial 1 is 1900-01-01 and serial 60 is 1900-02-29 — a day that never existed, kept for Lotus 1-2-3 compatibility. The effective day-zero anchor is therefore 1899-12-31 for serials 1–59 and 1899-12-30 from serial 61 onwards; `origin` shows the second one, which is why origin + minValue lands a day before this row's range starts."
    },
    {
      "id": "excel1904",
      "name": "Excel serial (1904 date system)",
      "origin": "1904-01-01T00:00:00.000000000Z",
      "unit": "day",
      "resolution": "1 day, fractional (Excel stores serials as IEEE-754 doubles, ≈1 µs near today)",
      "minValue": "0",
      "maxValue": "2957003.999999999999988",
      "range": "1904-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z",
      "typicalSource": "Legacy Excel for Mac workbooks and files converted from them",
      "specification": "Microsoft — Date systems in Excel",
      "specificationUrl": "https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487",
      "note": "Serial 0 is 1904-01-01 and there is no leap-year bug. For the same date the 1900-system serial is always exactly 1462 higher: Microsoft's own example, 2011-07-05, is 40729 here and 39267 there."
    }
  ],
  "meta": {
    "endpoint": "epoch",
    "count": 2,
    "params": {
      "search": "excel"
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

Timestamps that come from Windows /api/epoch?search=windows

GET /api/epoch?search=windows

{
  "data": [
    {
      "id": "filetime",
      "name": "Windows FILETIME",
      "origin": "1601-01-01T00:00:00.000000000Z",
      "unit": "100-nanosecond interval",
      "resolution": "100 ns",
      "minValue": "0",
      "maxValue": "18446744073709551615",
      "range": "1601-01-01T00:00:00.000000000Z … +060056-05-28T05:36:10.955161500Z",
      "typicalSource": "Windows GetSystemTimeAsFileTime, NTFS $MFT records, Active Directory lastLogonTimestamp, ETW",
      "specification": "Microsoft FILETIME structure (minwinbase.h)",
      "specificationUrl": "https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime",
      "note": "An unsigned 64-bit count of 100-nanosecond intervals since 1601-01-01 (UTC). The Unix epoch is exactly 116444736000000000, the constant Microsoft's own time_t conversion sample adds. Chrome/WebKit profile timestamps (History.visit_time, Cookies.creation_utc) share the 1601 epoch but count MICROSECONDS — multiply such a value by 10 before using from=filetime, or a present-day timestamp decodes to the 1640s."
    },
    {
      "id": "excel",
      "name": "Excel serial (1900 date system)",
      "origin": "1899-12-30T00:00:00.000000000Z",
      "unit": "day",
      "resolution": "1 day, fractional (Excel stores serials as IEEE-754 doubles, ≈1 µs near today)",
      "minValue": "1",
      "maxValue": "2958465.999999999999988",
      "range": "1900-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z",
      "typicalSource": "Excel for Windows, .xlsx numeric date cells, CSV exports, Lotus 1-2-3",
      "specification": "Microsoft — Date systems in Excel",
      "specificationUrl": "https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487",
      "note": "Serial 1 is 1900-01-01 and serial 60 is 1900-02-29 — a day that never existed, kept for Lotus 1-2-3 compatibility. The effective day-zero anchor is therefore 1899-12-31 for serials 1–59 and 1899-12-30 from serial 61 onwards; `origin` shows the second one, which is why origin + minValue lands a day before this row's range starts."
    }
  ],
  "meta": {
    "endpoint": "epoch",
    "count": 2,
    "params": {
      "search": "windows"
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

The epoch table as CSV /api/epoch?format=csv

GET /api/epoch?format=csv

id,name,origin,unit,resolution,minValue,maxValue,range,typicalSource,specification,specificationUrl,note
unix,Unix time (seconds),1970-01-01T00:00:00.000000000Z,second,1 s (a decimal fraction is accepted and emitted),-8640000000000,8640000000000,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"POSIX time_t, date +%s, JWT iat/exp (RFC 7519 NumericDate), RADIUS Event-Timestamp (RFC 2869 §5.3), Stripe API created",POSIX.1-2024 (Issue 8) §4.19 Seconds Since the Epoch,https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19,"POSIX accounts for every day as exactly 86400 seconds, so Unix time contains no leap seconds and neither does this endpoint. The count itself has no native bound; the range shown is this API's own instant limit."
unixMs,Unix time (milliseconds),1970-01-01T00:00:00.000000000Z,millisecond,1 ms (a decimal fraction is accepted and emitted),-8640000000000000,8640000000000000,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"JavaScript Date.now(), Java System.currentTimeMillis(), Kafka, MongoDB, Microsoft /Date(…)/ JSON","POSIX epoch scaled by 1000 (a de-facto convention, not a POSIX unit)",https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19,"Same epoch as Unix seconds, ×1000. This is the pair that silently breaks: 1751000000 is a plausible seconds value AND a plausible milliseconds value, which is why `from` is required. Microsoft's /Date(700000+0500)/ JSON wire format counts in this unit too, despite the tick-shaped digits: the number is milliseconds since midnight 1970-01-01 GMT and the suffix only records the original local offset."
unixUs,Unix time (microseconds),1970-01-01T00:00:00.000000000Z,microsecond,1 µs (a decimal fraction is accepted and emitted),-8640000000000000000,8640000000000000000,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"systemd journal __REALTIME_TIMESTAMP, Parquet and Arrow TIMESTAMP_MICROS, Cassandra WRITETIME, date +%s%6N","POSIX epoch scaled by 10^6 (a de-facto convention, not a POSIX unit)",https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19,"Same epoch as Unix seconds, ×1000000. Two microsecond counters that are NOT this one: PostgreSQL stores its internal timestamps in microseconds since 2000-01-01, and a Chrome trace event's `ts` is microseconds on the tracing clock, which is monotonic rather than counted from 1970."
unixNs,Unix time (nanoseconds),1970-01-01T00:00:00.000000000Z,nanosecond,1 ns,-8640000000000000000000,8640000000000000000000,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"Go time.UnixNano(), clock_gettime(), InfluxDB, OpenTelemetry spans","POSIX epoch scaled by 10^9 (a de-facto convention, not a POSIX unit)",https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_19,"This is the endpoint's internal resolution, so every conversion is exact at nanosecond scale. A signed 64-bit nanosecond counter only spans 1677–2262, which is narrower than the range shown here."
iso,ISO 8601 / RFC 3339 date-time,,calendar date-time (not a counter),1 ns (fractional seconds are capped at 9 digits),0001-01-01T00:00:00.000000000Z,9999-12-31T23:59:59.999999999Z,0001-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z,"Structured logs, JSON APIs, date -Is, XML schema dateTime",RFC 3339 §5.6 Internet Date/Time Format,https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6,"Not an epoch — a calendar rendering. Input must be YYYY-MM-DD or a full date-time carrying Z or an explicit ±HH:MM offset; T and Z may be lower case. RFC 3339 allows second 60 for a leap second, which Unix time cannot represent, so this endpoint rejects it."
filetime,Windows FILETIME,1601-01-01T00:00:00.000000000Z,100-nanosecond interval,100 ns,0,18446744073709551615,1601-01-01T00:00:00.000000000Z … +060056-05-28T05:36:10.955161500Z,"Windows GetSystemTimeAsFileTime, NTFS $MFT records, Active Directory lastLogonTimestamp, ETW",Microsoft FILETIME structure (minwinbase.h),https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime,"An unsigned 64-bit count of 100-nanosecond intervals since 1601-01-01 (UTC). The Unix epoch is exactly 116444736000000000, the constant Microsoft's own time_t conversion sample adds. Chrome/WebKit profile timestamps (History.visit_time, Cookies.creation_utc) share the 1601 epoch but count MICROSECONDS — multiply such a value by 10 before using from=filetime, or a present-day timestamp decodes to the 1640s."
ticks,.NET DateTime ticks,0001-01-01T00:00:00.000000000Z,100-nanosecond interval,100 ns,0,3155378975999999999,0001-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999900Z,".NET DateTime.Ticks and DateTimeOffset.UtcTicks, SQL Server datetime2 round-trips",Microsoft .NET DateTime.Ticks property,https://learn.microsoft.com/en-us/dotnet/api/system.datetime.ticks,"100-nanosecond intervals since 12:00:00 midnight, January 1, 0001. The offset to the Unix epoch is exactly 621355968000000000 ticks — the number assistants most often hallucinate — and DateTime.MaxValue.Ticks is 3155378975999999999. Microsoft's serialized /Date(…)/ JSON is NOT a tick count despite the name it is usually given: that number is milliseconds since 1970-01-01 GMT, so use from=unixMs for it."
excel,Excel serial (1900 date system),1899-12-30T00:00:00.000000000Z,day,"1 day, fractional (Excel stores serials as IEEE-754 doubles, ≈1 µs near today)",1,2958465.999999999999988,1900-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z,"Excel for Windows, .xlsx numeric date cells, CSV exports, Lotus 1-2-3",Microsoft — Date systems in Excel,https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487,"Serial 1 is 1900-01-01 and serial 60 is 1900-02-29 — a day that never existed, kept for Lotus 1-2-3 compatibility. The effective day-zero anchor is therefore 1899-12-31 for serials 1–59 and 1899-12-30 from serial 61 onwards; `origin` shows the second one, which is why origin + minValue lands a day before this row's range starts."
excel1904,Excel serial (1904 date system),1904-01-01T00:00:00.000000000Z,day,"1 day, fractional (Excel stores serials as IEEE-754 doubles, ≈1 µs near today)",0,2957003.999999999999988,1904-01-01T00:00:00.000000000Z … 9999-12-31T23:59:59.999999999Z,Legacy Excel for Mac workbooks and files converted from them,Microsoft — Date systems in Excel,https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487,"Serial 0 is 1904-01-01 and there is no leap-year bug. For the same date the 1900-system serial is always exactly 1462 higher: Microsoft's own example, 2011-07-05, is 40729 here and 39267 there."
cocoa,Apple Foundation / Cocoa reference date,2001-01-01T00:00:00.000000000Z,second,1 s (a decimal fraction is accepted and emitted),-8640978307200,8639021692800,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"NSDate/Date timeIntervalSinceReferenceDate, macOS & iOS binary plists, Core Data, Safari history",Apple — Dates and Times Programming Topics (NSDate reference date),https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DatesAndTimes/Articles/dtDates.html,"Seconds relative to the first instant of 2001-01-01 GMT, so anything before 2001 is negative. NSDate stores this as a floating-point NSTimeInterval; this endpoint keeps it exact instead."
hfs,HFS+ / classic Mac OS timestamp,1904-01-01T00:00:00.000000000Z,second,1 s (HFS+ itself stores whole seconds),0,4294967295,1904-01-01T00:00:00.000000000Z … 2040-02-06T06:28:15.000000000Z,"HFS+ catalog records (create/content-modify/backup dates), HFS+ volume headers, classic Mac OS file dates",Apple Technical Note TN1150 — HFS Plus Volume Format,https://developer.apple.com/library/archive/technotes/tn/tn1150.html,"An unsigned 32-bit second count from midnight 1904-01-01 GMT, which is how TN1150 defines catalog dates — this endpoint reads values as UTC accordingly. The one exception in the format is the volume header's creation date, which TN1150 stores in LOCAL time, so those specific values arrive shifted by the recording machine's offset."
ntp,NTP timestamp (era 0 seconds),1900-01-01T00:00:00.000000000Z,second (32-bit seconds + 32-bit binary fraction),2⁻³² s ≈ 0.23 ns in the wire format; this endpoint carries 1 ns,0,4294967295.999999999,1900-01-01T00:00:00.000000000Z … 2036-02-07T06:28:15.999999999Z,"NTP/SNTP packets, ntpq output, RTCP sender reports (RFC 3550 §6.4.1)",RFC 5905 §6 (NTP timestamp format),https://www.rfc-editor.org/rfc/rfc5905.html#section-6,"Era 0 only, whose prime epoch is 0 h 1 January 1900 UTC. The 32-bit seconds field wraps at 2036-02-07T06:28:16Z, when era 1 begins; this endpoint never guesses an era. Two fields that sound like NTP are not: RADIUS Event-Timestamp counts seconds since 1970 (RFC 2869 §5.3 — use from=unix), and Kerberos carries KerberosTime, an ASN.1 GeneralizedTime string rather than any second count."
julianDay,Julian Day (JD),-004713-11-24T12:00:00.000000000Z,day,"1 day, fractional",-97559412.5,102440587.5,-271821-04-20T00:00:00.000000000Z … +275760-09-13T00:00:00.000000000Z,"Astronomy software, ephemerides, SPICE kernels, variable-star catalogues",US Naval Observatory — Julian date definition,https://aa.usno.navy.mil/faq/JD_formula,"A continuous day count that STARTS AT NOON UT, so the Unix epoch is JD 2440587.5. JD 0 is 4713 BC January 1 at Greenwich mean noon in the proleptic JULIAN calendar; the very same instant is -4713-11-24T12:00Z in the proleptic Gregorian calendar this API uses everywhere else."

GET /api/epoch/convert Convert one declared timestamp into every supported representation Computed answer

Exact BigInt conversion between all thirteen representations plus a zoned wall-clock rendering. from is mandatory — nothing is auto-detected.

Live requestRuns against the public API

No key required

GET/api/epoch/convert?value=638000000000000000&from=ticks

Request parameters

valuerequired

The timestamp, interpreted strictly according to `from`. Numeric representations take a plain decimal (no exponent or separators, up to 25 integer and 15 fractional digits); `from=iso` takes YYYY-MM-DD or an RFC 3339 date-time with Z or an explicit offset, whose fractional seconds are capped at 9 digits (1 ns).

fromrequired

Which representation `value` is written in. Required on purpose: the same digits can be valid seconds and valid milliseconds, so this API never guesses.

tzdefault UTC

IANA timezone for the `local` rendering, case-insensitive (e.g. Europe/Copenhagen). Every numeric conversion stays UTC-based and is unaffected.

precisiondefault 3

Fractional-second digits in the `iso` and `local.dateTime` outputs. Truncated, never rounded, so the rendered value never jumps to the next second.

Advanced response options4 options

fields

Return only these fields (comma-separated). Mutually exclusive with 'exclude'.

exclude

Return all fields except these (comma-separated).

prettydefault false

Pretty-print the JSON response.

unwrapdefault false

Drop the envelope: return the raw array/object without data/meta wrapper.

Response

Example parameters are ready. Send the request to inspect the live response.

Route reference

Code, request parameters, response fields and verified examples 8 params · 20 fields · 6 examples

Code samples Ready-to-copy requests in 4 languages

curl JavaScript Python PHP

curl "https://randomapi.dev/api/epoch/convert?from=ticks&value=638000000000000000"

const res = await fetch("https://randomapi.dev/api/epoch/convert?from=ticks&value=638000000000000000");
const { data, meta } = await res.json();

import requests

data = requests.get("https://randomapi.dev/api/epoch/convert?from=ticks&value=638000000000000000").json()["data"]

$json = json_decode(file_get_contents(
  "https://randomapi.dev/api/epoch/convert?from=ticks&value=638000000000000000"
), true);
$data = $json["data"];

Parameters Route-specific request inputs 4

Parameter	Type	Default & allowed	Description
`value` required	string	allowed: 1 – 48 example: 638000000000000000	The timestamp, interpreted strictly according to `from`. Numeric representations take a plain decimal (no exponent or separators, up to 25 integer and 15 fractional digits); `from=iso` takes YYYY-MM-DD or an RFC 3339 date-time with Z or an explicit offset, whose fractional seconds are capped at 9 digits (1 ns).
`from` required	enum	allowed: unix \| unixMs \| unixUs \| unixNs \| iso \| filetime \| ticks \| excel \| excel1904 \| cocoa \| hfs \| ntp \| julianDay example: ticks	Which representation `value` is written in. Required on purpose: the same digits can be valid seconds and valid milliseconds, so this API never guesses.
`tz`	string	default: UTC example: Europe/Copenhagen	IANA timezone for the `local` rendering, case-insensitive (e.g. Europe/Copenhagen). Every numeric conversion stays UTC-based and is unaffected.
`precision`	int	default: 3 allowed: 0 – 9 example: 9	Fractional-second digits in the `iso` and `local.dateTime` outputs. Truncated, never rounded, so the rendered value never jumps to the next second.

value string required

allowed: 1 – 48

example: value=638000000000000000

from enum required

Which representation `value` is written in. Required on purpose: the same digits can be valid seconds and valid milliseconds, so this API never guesses.

example: from=ticks

tz string

IANA timezone for the `local` rendering, case-insensitive (e.g. Europe/Copenhagen). Every numeric conversion stays UTC-based and is unaffected.

default: UTC

example: tz=Europe/Copenhagen

precision int

Fractional-second digits in the `iso` and `local.dateTime` outputs. Truncated, never rounded, so the rendered value never jumps to the next second.

default: 3

allowed: 0 – 9

example: precision=9

Universal parameters Shared response and formatting options 4

Parameter	Type	Default & allowed	Description
`fields`	list	example: from,input	Return only these fields (comma-separated). Mutually exclusive with 'exclude'.
`exclude`	list	example: notes	Return all fields except these (comma-separated).
`pretty`	boolean	default: false example: true	Pretty-print the JSON response.
`unwrap`	boolean	default: false example: true	Drop the envelope: return the raw array/object without data/meta wrapper.

fields list

Return only these fields (comma-separated). Mutually exclusive with 'exclude'.

example: fields=from,input

exclude list

Return all fields except these (comma-separated).

example: exclude=notes

pretty boolean

Pretty-print the JSON response.

default: false

example: pretty=true

unwrap boolean

Drop the envelope: return the raw array/object without data/meta wrapper.

default: false

example: unwrap=true

Response schema Fields returned in each record 20

Field	Type	Description	Example
`from`	string	The source representation you declared; never inferred from the value.	ticks
`input`	string	Your value in canonical form — a sign, no leading zeroes and no trailing fraction zeroes for numbers; upper-case T/Z for ISO input.	621355968000000000
`renderable`	boolean	Whether the instant falls inside the calendar rendering window (proleptic Gregorian years 0001–9999). Numeric conversions are still returned when it is false — unless `anomaly` is set, which means there is no instant at all and every conversion is null.	true
`anomaly` nullable	string	Set only when the input designates something that is not a real instant — currently only Excel 1900-system serial 60, the phantom 1900-02-29. Every conversion is null in that case.	null
`iso` nullable	string (RFC 3339)	The instant in UTC at the requested precision; fractional seconds are truncated, never rounded. Null when renderable is false.	1970-01-01T00:00:00.000Z
`unix` nullable	string (decimal)	Seconds since 1970-01-01T00:00:00Z.	0
`unixMs` nullable	string (decimal)	Milliseconds since the Unix epoch.	0
`unixUs` nullable	string (decimal)	Microseconds since the Unix epoch.	0
`unixNs` nullable	string (decimal)	Nanoseconds since the Unix epoch — this endpoint's exact internal unit.	0
`filetime` nullable	string (decimal)	100-nanosecond intervals since 1601-01-01T00:00:00Z (Windows FILETIME). A fractional part appears only for instants finer than 100 ns.	116444736000000000
`ticks` nullable	string (decimal)	100-nanosecond intervals since 0001-01-01T00:00:00Z (.NET DateTime.Ticks). Null beyond DateTime.MaxValue.	621355968000000000
`excel` nullable	string (decimal)	Excel 1900-system day serial, reproducing the 1900 leap-year bug. Null before 1900-01-01 and after 9999-12-31.	25569
`excel1904` nullable	string (decimal)	Excel 1904-system day serial, always exactly 1462 lower than the 1900-system serial. Null before 1904-01-01.	24107
`cocoa` nullable	string (decimal)	Seconds since 2001-01-01T00:00:00Z, Apple's Foundation/NSDate reference date; negative before 2001.	-978307200
`hfs` nullable	string (decimal)	Seconds since 1904-01-01T00:00:00Z, read as UTC because TN1150 defines HFS+ catalog dates in GMT — the one exception in the format is the volume header's creation date, which TN1150 stores in local time, so such a value arrives shifted by the recording machine's offset. Null outside the unsigned 32-bit range that ends 2040-02-06T06:28:15Z.	2082844800
`ntp` nullable	string (decimal)	NTP era-0 seconds since 1900-01-01T00:00:00Z. Null outside era 0, which ends at 2036-02-07T06:28:16Z.	2208988800
`ntp64` nullable	string (hex)	The same NTP timestamp as the wire format's 64-bit fixed point, written seconds.fraction in hexadecimal. The fraction is rounded to the nearest 2⁻³² s. Null on exactly the same bounds as `ntp`, and the single note about era 0 names both fields.	83aa7e80.00000000
`julianDay` nullable	string (decimal)	Julian Day, a fractional day count starting at noon UT; decimal-rounded to 15 fractional digits, which is finer than one nanosecond.	2440587.5
`local` nullable	object	The same instant on the requested zone's wall clock: zone, dateTime (no offset suffix), offset, offsetSeconds, weekday and isDst. Offsets come from the runtime's IANA database, so pre-standardisation dates get local mean time (seconds included) and far-future dates get today's rules projected forward. Null when the instant cannot be rendered.	{"zone":"UTC","dateTime":"1970-01-01T00:00:00.000","offset":"+00:00","offsetSeconds":0,"weekday":"Thursday","isDst":false}
`notes`	string[]	One line for every representation that could not hold the instant, plus one for any rounding that was applied — or a single line pointing at `anomaly` when the input designates no instant at all. Empty when every representation held the instant exactly.	[]

from string

The source representation you declared; never inferred from the value.

example: ticks

input string

Your value in canonical form — a sign, no leading zeroes and no trailing fraction zeroes for numbers; upper-case T/Z for ISO input.

example: 621355968000000000

renderable boolean

Whether the instant falls inside the calendar rendering window (proleptic Gregorian years 0001–9999). Numeric conversions are still returned when it is false — unless `anomaly` is set, which means there is no instant at all and every conversion is null.

example: true

anomaly string nullable

Set only when the input designates something that is not a real instant — currently only Excel 1900-system serial 60, the phantom 1900-02-29. Every conversion is null in that case.

example: null

iso string (RFC 3339) nullable

The instant in UTC at the requested precision; fractional seconds are truncated, never rounded. Null when renderable is false.

example: 1970-01-01T00:00:00.000Z

unix string (decimal) nullable

Seconds since 1970-01-01T00:00:00Z.

example: 0

unixMs string (decimal) nullable

Milliseconds since the Unix epoch.

example: 0

unixUs string (decimal) nullable

Microseconds since the Unix epoch.

example: 0

unixNs string (decimal) nullable

Nanoseconds since the Unix epoch — this endpoint's exact internal unit.

example: 0

filetime string (decimal) nullable

100-nanosecond intervals since 1601-01-01T00:00:00Z (Windows FILETIME). A fractional part appears only for instants finer than 100 ns.

example: 116444736000000000

ticks string (decimal) nullable

100-nanosecond intervals since 0001-01-01T00:00:00Z (.NET DateTime.Ticks). Null beyond DateTime.MaxValue.

example: 621355968000000000

excel string (decimal) nullable

Excel 1900-system day serial, reproducing the 1900 leap-year bug. Null before 1900-01-01 and after 9999-12-31.

example: 25569

excel1904 string (decimal) nullable

Excel 1904-system day serial, always exactly 1462 lower than the 1900-system serial. Null before 1904-01-01.

example: 24107

cocoa string (decimal) nullable

Seconds since 2001-01-01T00:00:00Z, Apple's Foundation/NSDate reference date; negative before 2001.

example: -978307200

hfs string (decimal) nullable

Seconds since 1904-01-01T00:00:00Z, read as UTC because TN1150 defines HFS+ catalog dates in GMT — the one exception in the format is the volume header's creation date, which TN1150 stores in local time, so such a value arrives shifted by the recording machine's offset. Null outside the unsigned 32-bit range that ends 2040-02-06T06:28:15Z.

example: 2082844800

ntp string (decimal) nullable

NTP era-0 seconds since 1900-01-01T00:00:00Z. Null outside era 0, which ends at 2036-02-07T06:28:16Z.

example: 2208988800

ntp64 string (hex) nullable

The same NTP timestamp as the wire format's 64-bit fixed point, written seconds.fraction in hexadecimal. The fraction is rounded to the nearest 2⁻³² s. Null on exactly the same bounds as `ntp`, and the single note about era 0 names both fields.

example: 83aa7e80.00000000

julianDay string (decimal) nullable

Julian Day, a fractional day count starting at noon UT; decimal-rounded to 15 fractional digits, which is finer than one nanosecond.

example: 2440587.5

local object nullable

The same instant on the requested zone's wall clock: zone, dateTime (no offset suffix), offset, offsetSeconds, weekday and isDst. Offsets come from the runtime's IANA database, so pre-standardisation dates get local mean time (seconds included) and far-future dates get today's rules projected forward. Null when the instant cannot be rendered.

example: {"zone":"UTC","dateTime":"1970-01-01T00:00:00.000","offset":"+00:00","offsetSeconds":0,"weekday":"Thursday","isDst":false}

notes string[]

One line for every representation that could not hold the instant, plus one for any rounding that was applied — or a single line pointing at `anomaly` when the input designates no instant at all. Empty when every representation held the instant exactly.

example: []

Documented examples

Build-generated requests and complete responses 6

.NET ticks to a date /api/epoch/convert?from=ticks&value=638000000000000000

GET /api/epoch/convert?from=ticks&value=638000000000000000

{
  "data": {
    "from": "ticks",
    "input": "638000000000000000",
    "renderable": true,
    "anomaly": null,
    "iso": "2022-09-28T22:13:20.000Z",
    "unix": "1664403200",
    "unixMs": "1664403200000",
    "unixUs": "1664403200000000",
    "unixNs": "1664403200000000000",
    "filetime": "133088768000000000",
    "ticks": "638000000000000000",
    "excel": "44832.925925925925926",
    "excel1904": "43370.925925925925926",
    "cocoa": "686096000",
    "hfs": "3747248000",
    "ntp": "3873392000",
    "ntp64": "e6df4580.00000000",
    "julianDay": "2459851.425925925925926",
    "local": {
      "zone": "UTC",
      "dateTime": "2022-09-28T22:13:20.000",
      "offset": "+00:00",
      "offsetSeconds": 0,
      "weekday": "Wednesday",
      "isDst": false
    },
    "notes": []
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "638000000000000000",
      "from": "ticks",
      "tz": "UTC",
      "precision": 3
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

FILETIME from an NTFS record /api/epoch/convert?from=filetime&value=133041600000000000

GET /api/epoch/convert?from=filetime&value=133041600000000000

{
  "data": {
    "from": "filetime",
    "input": "133041600000000000",
    "renderable": true,
    "anomaly": null,
    "iso": "2022-08-05T08:00:00.000Z",
    "unix": "1659686400",
    "unixMs": "1659686400000",
    "unixUs": "1659686400000000",
    "unixNs": "1659686400000000000",
    "filetime": "133041600000000000",
    "ticks": "637952832000000000",
    "excel": "44778.333333333333333",
    "excel1904": "43316.333333333333333",
    "cocoa": "681379200",
    "hfs": "3742531200",
    "ntp": "3868675200",
    "ntp64": "e6974c80.00000000",
    "julianDay": "2459796.833333333333333",
    "local": {
      "zone": "UTC",
      "dateTime": "2022-08-05T08:00:00.000",
      "offset": "+00:00",
      "offsetSeconds": 0,
      "weekday": "Friday",
      "isDst": false
    },
    "notes": []
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "133041600000000000",
      "from": "filetime",
      "tz": "UTC",
      "precision": 3
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

Excel serial 45000 /api/epoch/convert?from=excel&value=45000

GET /api/epoch/convert?from=excel&value=45000

{
  "data": {
    "from": "excel",
    "input": "45000",
    "renderable": true,
    "anomaly": null,
    "iso": "2023-03-15T00:00:00.000Z",
    "unix": "1678838400",
    "unixMs": "1678838400000",
    "unixUs": "1678838400000000",
    "unixNs": "1678838400000000000",
    "filetime": "133233120000000000",
    "ticks": "638144352000000000",
    "excel": "45000",
    "excel1904": "43538",
    "cocoa": "700531200",
    "hfs": "3761683200",
    "ntp": "3887827200",
    "ntp64": "e7bb8900.00000000",
    "julianDay": "2460018.5",
    "local": {
      "zone": "UTC",
      "dateTime": "2023-03-15T00:00:00.000",
      "offset": "+00:00",
      "offsetSeconds": 0,
      "weekday": "Wednesday",
      "isDst": false
    },
    "notes": []
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "45000",
      "from": "excel",
      "tz": "UTC",
      "precision": 3
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

Excel serial 60 is not a date /api/epoch/convert?from=excel&value=60

GET /api/epoch/convert?from=excel&value=60

{
  "data": {
    "from": "excel",
    "input": "60",
    "renderable": false,
    "anomaly": "Excel serial 60 is 1900-02-29 in the 1900 date system, a date that has never existed: Excel deliberately treats 1900 as a leap year for Lotus 1-2-3 compatibility. No instant corresponds to this serial, so no conversion is offered rather than silently returning 1900-02-28 or 1900-03-01.",
    "iso": null,
    "unix": null,
    "unixMs": null,
    "unixUs": null,
    "unixNs": null,
    "filetime": null,
    "ticks": null,
    "excel": null,
    "excel1904": null,
    "cocoa": null,
    "hfs": null,
    "ntp": null,
    "ntp64": null,
    "julianDay": null,
    "local": null,
    "notes": [
      "Every conversion is null: 'value' designates no instant at all, so there is nothing to express in another representation — see 'anomaly'."
    ]
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "60",
      "from": "excel",
      "tz": "UTC",
      "precision": 3
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

Unix milliseconds on a Tokyo clock /api/epoch/convert?from=unixMs&value=1751000000000&tz=Asia/Tokyo

GET /api/epoch/convert?from=unixMs&value=1751000000000&tz=Asia/Tokyo

{
  "data": {
    "from": "unixMs",
    "input": "1751000000000",
    "renderable": true,
    "anomaly": null,
    "iso": "2025-06-27T04:53:20.000Z",
    "unix": "1751000000",
    "unixMs": "1751000000000",
    "unixUs": "1751000000000000",
    "unixNs": "1751000000000000000",
    "filetime": "133954736000000000",
    "ticks": "638865968000000000",
    "excel": "45835.203703703703704",
    "excel1904": "44373.203703703703704",
    "cocoa": "772692800",
    "hfs": "3833844800",
    "ntp": "3959988800",
    "ntp64": "ec08a240.00000000",
    "julianDay": "2460853.703703703703704",
    "local": {
      "zone": "Asia/Tokyo",
      "dateTime": "2025-06-27T13:53:20.000",
      "offset": "+09:00",
      "offsetSeconds": 32400,
      "weekday": "Friday",
      "isDst": false
    },
    "notes": []
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "1751000000000",
      "from": "unixMs",
      "tz": "Asia/Tokyo",
      "precision": 3
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

ISO timestamp to every epoch, nanosecond precision /api/epoch/convert?from=iso&value=2026-07-04T12:34:56.789Z&precision=9

GET /api/epoch/convert?from=iso&value=2026-07-04T12:34:56.789Z&precision=9

{
  "data": {
    "from": "iso",
    "input": "2026-07-04T12:34:56.789Z",
    "renderable": true,
    "anomaly": null,
    "iso": "2026-07-04T12:34:56.789000000Z",
    "unix": "1783168496.789",
    "unixMs": "1783168496789",
    "unixUs": "1783168496789000",
    "unixNs": "1783168496789000000",
    "filetime": "134276420967890000",
    "ticks": "639187652967890000",
    "excel": "46207.524268391203704",
    "excel1904": "44745.524268391203704",
    "cocoa": "804861296.789",
    "hfs": "3866013296.789",
    "ntp": "3992157296.789",
    "ntp64": "edf37c70.c9fbe76d",
    "julianDay": "2461226.024268391203704",
    "local": {
      "zone": "UTC",
      "dateTime": "2026-07-04T12:34:56.789000000",
      "offset": "+00:00",
      "offsetSeconds": 0,
      "weekday": "Saturday",
      "isDst": false
    },
    "notes": []
  },
  "meta": {
    "endpoint": "epoch",
    "route": "/convert",
    "params": {
      "value": "2026-07-04T12:34:56.789Z",
      "from": "iso",
      "tz": "UTC",
      "precision": 9
    },
    "generatedAt": "2026-07-29T08:13:22.000Z"
  }
}

About this API

Coverage, behavior and common use cases

Coverage & behavior

One declared timestamp in, thirteen representations out, computed with BigInt integer arithmetic over fixed epoch offsets — no floating point, so a .NET tick value or a nanosecond count survives the round trip unchanged.

from is required and never guessed. 1751000000 is a perfectly plausible Unix seconds value and a perfectly plausible Unix milliseconds value, and a confidently wrong date is worse than an error, so this API refuses to auto-detect.

The offsets, each taken from the primary specification: FILETIME counts 100-nanosecond intervals from 1601-01-01 (the Unix epoch is exactly 116444736000000000); .NET ticks count 100-nanosecond intervals from 0001-01-01 (the Unix epoch is exactly 621355968000000000); Excel's 1900 serials sit 1462 above the same date's 1904 serial; Cocoa counts seconds from 2001-01-01; HFS+ from 1904-01-01; NTP from 1900-01-01; and Julian Day is a fractional day count that starts at noon, putting the Unix epoch at JD 2440587.5.

What this endpoint deliberately will not do:

No leap seconds, and therefore no GPS or TAI. POSIX accounts for every day as exactly 86400 seconds, so Unix time skips leap seconds and so does this API. GPS and TAI differ from UTC by a whole number of leap seconds that only the IANA leap-second table knows, and converting them without it produces a silently wrong instant — so they are unsupported rather than approximated. from=iso likewise rejects the RFC 3339 leap-second value :60, because no Unix instant corresponds to it.
No correcting Excel. The 1900 leap-year bug is reproduced: serial 60 is 1900-02-29, a day that never existed, and it comes back as an anomaly with every conversion null instead of a plausible-looking neighbouring date. Serials 1–59 therefore anchor to 1899-12-31 and serials from 61 to 1899-12-30.
No pretending the range is wider than the calendar. Numeric conversion happens for any instant inside ±100,000,000 days of the Unix epoch, but calendar rendering (iso and local) is limited to proleptic Gregorian years 0001–9999, the four-digit range RFC 3339 profiles. Outside it you get renderable: false with a reason, not a spurious 400. A FILETIME at its unsigned 64-bit maximum lands in the year 60056 and is handled exactly that way. Each representation still enforces its own native bounds on input — a negative FILETIME, a tick past DateTime.MaxValue or an Excel serial below 1 is a 400 that names the real limits — and any representation that cannot hold the resulting instant comes back null with the reason in notes.
No guessing an NTP era. RFC 5905's 32-bit seconds field wraps at 2036-02-07T06:28:16Z; from=ntp therefore covers era 0 only (1900-01-01 onwards) and instants past the rollover return ntp: null rather than a value that silently means the wrong century.
No certified ISO conformance claim. ISO 8601 itself is paywalled; this endpoint implements and cites RFC 3339, its public profile.

Values are strings on the way in and out, so nothing is clipped by JavaScript's 2^53 safe-integer limit. Sub-second inputs finer than one nanosecond are rejected rather than rounded, with one documented exception: a fractional day serial (Excel or Julian Day) is almost never a whole number of nanoseconds, so it is rounded to the nearest nanosecond and the response says so in notes. Day serials come back rounded to 15 fractional digits — finer than a nanosecond, so feeding one straight back reproduces the same instant.

Use it for

Decode a .NET DateTime.Ticks or Windows FILETIME value pulled from a log, registry hive or Active Directory attribute
Turn an Excel date column that exported as raw serial numbers back into real dates, bug and all
Line up traces whose spans use Unix nanoseconds against logs that use ISO 8601
Check whether a Mac plist timestamp is a Cocoa reference-date value or an HFS+ 1904 second count
Read the seconds field of an NTP packet capture without hand-subtracting 2208988800

Frequently asked questions

Practical answers about this endpoint 6

How do I convert .NET DateTime ticks to a date?

Call /api/epoch/convert?from=ticks&value=638000000000000000. Ticks are 100-nanosecond intervals since 0001-01-01, so the offset to the Unix epoch is exactly 621355968000000000 ticks — subtract it, then divide by 10,000,000 for Unix seconds.

Why does Excel serial number 60 not return a date?

Because it is 1900-02-29, a day that never existed: Excel keeps the Lotus 1-2-3 assumption that 1900 was a leap year. This endpoint returns an anomaly explaining that and leaves every conversion null, rather than quietly answering 1900-02-28 or 1900-03-01.

Why do I have to tell the API which format my number is in?

Because 1751000000 is a valid Unix seconds value (2025) and a valid Unix milliseconds value (1970), and no cutoff heuristic can tell them apart safely. from is required and there is no auto-detection.

Does this converter handle GPS time or TAI?

No, deliberately. GPS and TAI differ from UTC by a whole number of leap seconds that requires the IANA leap-second table; without it every conversion would be silently wrong by seconds, so they are excluded rather than approximated.

What is the difference between the 1900 and 1904 Excel date systems?

Exactly 1462 days. The 1900-system serial for a date is always 1462 higher than its 1904-system serial — Microsoft's own example, 2011-07-05, is 40729 and 39267 — and only the 1900 system carries the phantom leap day.

Can it convert timestamps outside the years 1970–2100?

Yes. FILETIME from 1601, .NET ticks from 0001 and negative Julian Days are all converted numerically. Calendar rendering (iso and local) covers proleptic Gregorian years 0001–9999; beyond that the response sets renderable: false and still returns every number.

Standards & references

Primary sources behind the contract

Useful next tools in the catalog

Current Time API REAL DATA

Current time in any IANA timezone — UTC instant, unix seconds, local date & time, UTC offset, ISO week, day of year and a live DST flag.

Date Info API REAL DATA

Real calendar facts for any date — weekday, ISO week, day of year, quarter, leap year, days in month, weekend flag and Unix timestamp. Defaults to today.

Timezone Database API REAL DATA

Live IANA offsets, DST transitions, local-time ambiguity resolution and exact instant conversion — no guessed wall-clock mappings.

Random Date Generator API MOCK DATA

Uniformly random timestamps from any date range — ISO instant, Unix seconds, date, time and weekday — with an exact weekdays-only mode and seeded results.

Business Days Calculator API REAL DATA

Add, count or inspect business days using verified national public-holiday rules for 61 countries, including observed substitute days.

GET /api/epoch Every supported epoch with its origin, unit, resolution and range Returns a list

Request parameters

Response

Route reference

Documented examples

GET /api/epoch/convert Convert one declared timestamp into every supported representation Computed answer

Request parameters

Response

Route reference

Documented examples

About this API

Coverage & behavior

Use it for

Frequently asked questions

Standards & references

Related APIs