Why turn dates into epoch numbers
Many APIs, databases and caches want time as a number: Redis EXPIREAT, JWT exp claims, query parameters like ?since=, Prometheus and InfluxDB queries, or a BIGINT column. Getting that number right means knowing which time zone a date was written in, which is exactly where hand calculations go wrong. This converter makes the zone explicit and warns you when a local time is ambiguous.
Accepted date formats
Write one date per line. Supported forms:
- ISO 8601 / RFC 3339:
2026-09-14T08:21:05Z,2026-09-14 16:21:05+08:00, basic format20260914T082105Z, and reduced precision such as2026-09-14(midnight) or2026-09-14T08:21. - Fractional seconds with
.or,, up to nanoseconds:08:21:05.123456789Z. - Offsets as
Z,+08,+08:00or+0800, and a trailingUTCorGMT. - ISO week dates (
2026-W38-1) and ordinal dates (2026-257). - Slashed dates:
2026/09/14 08:21:05. - RFC 2822 email dates:
Mon, 14 Sep 2026 08:21:05 GMT, with numeric offsets (+0800) or US zone names (EST,PDT…), and two-digit years. - asctime / HTTP dates such as
Mon Sep 14 08:21:05 2026, which are always UTC. 24:00as the midnight at the end of a day.
Blank lines and lines starting with # are skipped.
Time zone
A date that carries its own offset (Z, +05:30, GMT) is converted exactly as written; the option has no effect on it. A date without an offset is read as wall-clock time in the Time zone option: UTC by default, any IANA name such as Europe/London, or local for this device’s zone.
Wall-clock times can be ambiguous around daylight-saving changes:
- In the spring gap (e.g.
2026-03-08T02:30inAmerica/New_York), the time never happened. The converter uses the instant after clocks jumped forward and warns:… does not exist in America/New_York (clocks skipped forward); used 03:30:00-04:00. - In the autumn overlap, the time happens twice. The earlier instant is used and a warning says so.
Validation and output
Each component is range-checked rather than rolled over: 2026-02-30 is rejected with February 2026 has 28 days, and hour 25 or minute 60 are errors. A leap second (23:59:60) is rejected because Unix time cannot represent it. In RFC 2822 dates, a weekday that does not match the date produces a warning.
For every valid line you get the epoch time in seconds and milliseconds — with exact decimals when the input had sub-second digits — and the instant in UTC ISO format for confirmation. Invalid lines are reported individually while the valid ones still convert, so a pasted column of dates never fails as a whole. Use the Unix timestamp converter for the opposite direction. Everything is computed locally.
Examples
Same instant, three notations
All three lines describe one moment, so all three produce the same seconds and milliseconds.
2026-09-14T08:21:05Z
2026-09-14 16:21:05+08:00
Mon, 14 Sep 2026 08:21:05 GMT2026-09-14T08:21:05Z
Seconds 1789374065
Milliseconds 1789374065000
UTC 2026-09-14T08:21:05.000Z
2026-09-14 16:21:05+08:00
Seconds 1789374065
Milliseconds 1789374065000
UTC 2026-09-14T08:21:05.000Z
Mon, 14 Sep 2026 08:21:05 GMT
Seconds 1789374065
Milliseconds 1789374065000
UTC 2026-09-14T08:21:05.000Z
Local times in New York, including a DST gap
Times without an offset use the chosen zone; the second line falls in the spring-forward gap and the third in the autumn overlap, each with a warning.
2026-07-04 09:00
2026-03-08T02:30:00
2026-11-01T01:30:002026-07-04 09:00
Seconds 1783170000
Milliseconds 1783170000000
UTC 2026-07-04T13:00:00.000Z
2026-03-08T02:30:00
Seconds 1772955000
Milliseconds 1772955000000
UTC 2026-03-08T07:30:00.000Z
2026-11-01T01:30:00
Seconds 1793511000
Milliseconds 1793511000000
UTC 2026-11-01T05:30:00.000Z
Week, ordinal and high-precision dates
ISO week and ordinal dates resolve to calendar days, and nanosecond digits come through as exact decimal seconds.
2026-W38-1
2026-257
2026-09-14T08:21:05.123456789Z2026-W38-1
Seconds 1789344000
Milliseconds 1789344000000
UTC 2026-09-14T00:00:00.000Z
2026-257
Seconds 1789344000
Milliseconds 1789344000000
UTC 2026-09-14T00:00:00.000Z
2026-09-14T08:21:05.123456789Z
Seconds 1789374065.123456789
Milliseconds 1789374065123.456789
UTC 2026-09-14T08:21:05.123456789Z
Common errors and how to fix them
| Error | Cause | Fix |
|---|---|---|
Could not read "1789475200" as a date | The line is already a Unix timestamp, not a date. | Use the Unix timestamp converter to turn epoch numbers into dates. |
February 2026 has 28 days, so day 30 does not exist | The day is outside the month, often from date arithmetic done by hand. | Correct the day; dates are validated, not rolled over into the next month. |
Second 60 (a leap second) cannot be represented in Unix time | The input is a leap-second timestamp such as 2016-12-31T23:59:60Z. | Use 23:59:59 or the following 00:00:00, depending on how your system smears leap seconds. |
Tuesday does not match the date, which is a Monday | A warning: an RFC 2822 date names the wrong weekday. | Check whether the weekday or the date is the typo; the date itself is what gets converted. |
Unknown time zone "PST8" | The Time zone option is not a recognised IANA name. | Use a full zone name such as America/Los_Angeles. |
Frequently asked questions
Which time zone is used for a date without an offset?
The one in the Time zone option, UTC by default. Dates with Z or a numeric offset ignore the option.
Does it output seconds or milliseconds?
Both, on separate lines. Seconds suit Unix tools and JWTs; milliseconds suit JavaScript and Java.
What happens to a local time that occurs twice when clocks go back?
The earlier of the two instants is used, and a warning shows which offset was chosen.
Can I paste dates from an email header or HTTP response?
Yes. RFC 2822 dates like Mon, 14 Sep 2026 08:21:05 GMT and asctime-style HTTP dates are both understood.