Date Format Converter

Three systems, three date formats, one instant

You are chasing a provisioning bug across four places at once. The service log says 2026-08-13T09:31:20Z. The captured HTTP response says Thu, 13 Aug 2026 09:31:20 GMT. The queue message carries 1786613480. And the spreadsheet someone exported from the billing system has 46247.396759 sitting in the column labelled activated. Four values, one moment, and the only way to be sure of that is to convert them all into a common form. This page does the four conversions in one pass so you can get back to the actual bug.

The formats differ because they were designed for different jobs, not out of carelessness. RFC 3339 pinned down a strict, sortable profile of ISO 8601 for machine interchange, which is why it is what an API should emit. The day-month-year form with a comma after the weekday came from email long before that and is now frozen into HTTP: RFC 9110 still requires exactly that shape in a Date header. Epoch counts are what you store when you want arithmetic to be trivial. And a spreadsheet serial is a plain number of days that only looks like a date because of how the cell is formatted — change the format and the date turns back into 46247.4 in front of you.

The trap that catches people is not the conversion, it is the reading. A bare 2026-08-13 and 2026-08-13T00:00:00 are the same calendar day but not the same instant: ECMA-262 specifies the date-only form as UTC and the date-time form without an offset as local. On a machine running eight hours behind UTC, the second one is the previous evening. That is the single most common date bug in JavaScript, and nothing about either string announces it, so this page states which reading applied every time.

Bare numbers get the same treatment: the control above the input decides whether a number is an epoch count or a spreadsheet serial, because the digits cannot. Everything runs in your browser — no timestamp you paste here leaves the page.

Reading a date somebody else wrote

1. Paste the value – ISO 8601, an email or HTTP Date line, a bare epoch number, or a spreadsheet serial. The chip in the panel header names the form that was recognised.
2. Say how a bare number should be read – Epoch is the default. Switch it to a spreadsheet reading when the number came out of an export — a five-digit number is almost always a serial, and a ten-digit one is almost always epoch seconds.
3. Choose the zone for the zoned row – The offset shown next to it is the real offset for that zone at that instant, daylight saving included, so a January value and a July value in the same zone will differ.
4. Copy the row you need – Each row has its own copy button, including the epoch rows, which are the ones most likely to be pasted straight into a query.

If a date is landing on the day before, look for a missing T before you look at your timezone library. new Date('2026-08-13') gives you UTC midnight; new Date('2026-08-13T00:00:00') gives you local midnight. Anyone west of Greenwich who formats the first one back for display gets 12 August. The fix is almost never a library — it is deciding whether you meant a calendar day or an instant, and writing the string that says so.

Serial 60, the day that never happened

Spreadsheet serials are the format most likely to be quietly wrong, and the reason is a bug that is now older than most of the people hitting it. Excel's 1900 system treats 1900 as a leap year and counts a 29 February 1900 that the calendar never had. Lotus 1-2-3 had the bug first, Excel copied it deliberately so that files and formulas would keep matching, and Microsoft documents it as intentional rather than something anyone plans to fix. Paste 60 and then 61 into this page and watch what happens.

what Excel shows in the cell
60   29 February 1900
61   1 March 1900

what the calendar actually has
1900-03-01T00:00:00Z   phantom day
1900-03-01T00:00:00Z

Serial 59 is 28 February 1900 and serial 61 is 1 March 1900, which leaves serial 60 with nowhere real to go. Everything from 61 onward — every date anyone actually has — stays consistent, because the phantom day is already absorbed by then. The "my dates are one day out" reports therefore involve either a pre-1900 value or two tools that disagree about correcting for the phantom day. The 1904 system, which old Mac Excel used and which still turns up inside workbooks today, has no such bug and simply starts counting four years later: a sheet out by exactly 1,462 days is that difference and not a timezone. Excel to JSON converts the serials for you, and CSV vs Excel for tabular data covers the rest of what a spreadsheet does to your data on the way in.

When you reach for this

Matching a log line against a spreadsheet export

A SIM provisioning record shows up twice: once in a service log as an ISO timestamp and once in a billing export as a serial. Converting both here tells you in seconds whether the two rows describe the same activation or two attempts four hours apart — and the second answer is usually the interesting one.

Checking an HTTP Date header against your own clock

Caching bugs, expiring signed URLs and "this request is too old" rejections all come down to comparing a header written in the RFC 2822 shape against an epoch number your service computed. They are not directly comparable, which is exactly why the mismatch survives a code review.

A sheet whose dates are all out by the same amount

One day out points at the 1900 leap-year quirk or a UTC-versus-local read; 1,462 days out points at the 1904 system. Converting one known-good row here identifies which of the two you are looking at before you write any correction.

Deciding what an API should emit

If you are designing the payload rather than debugging it, emit RFC 3339 with an explicit offset and let clients derive the rest. Paste a sample body into JSON to Table afterwards — seeing every timestamp field in one column is the quickest way to spot the one endpoint that emits something else.

What this page does

• Detects ISO 8601 and RFC 3339, the RFC 2822 form used by email and HTTP headers, bare epoch counts and spreadsheet serials, and tells you which one it matched.
• Shows the zoned row with the zone's real offset at that instant, built from the browser's own zone data, so daylight saving and half-hour zones like Asia/Kolkata come out right.
• Keeps a long epoch value as digits rather than putting it through a floating-point conversion that would round a nanosecond timestamp before you ever saw it.
• Flags serial 60 as the phantom 29 February 1900 instead of quietly returning a date for it, and offers the 1904 system for workbooks that use it.
• Runs entirely in your browser — nothing you paste is sent anywhere.

Questions that come up

Is RFC 2822 just ISO 8601 written differently?

No, and treating them as interchangeable is a real source of bugs. They order the components differently, spell the month as an abbreviated English name rather than a number, and handle zones differently — RFC 2822 permits alphabetic abbreviations, ISO 8601 does not. Only one of them sorts correctly as plain text, which is a large part of why RFC 3339 exists. Use the day-month-year form where a protocol demands it, such as an HTTP Date header, and ISO everywhere else.

What timezone are the epoch rows in?

None, and that is the point. An epoch count is a number of seconds since a fixed instant, so it names a moment without naming a place. The zone only enters when you format it for a human — which is where two services can hold the identical number and print two different days.

Why do I have to tell it whether a number is epoch or a serial?

Because the number cannot tell you. 46247 is a perfectly good spreadsheet serial for 13 August 2026 and a perfectly good epoch value for 12:50 on 1 January 1970. Guessing by magnitude works often enough to be dangerous rather than often enough to be safe, so the choice is yours to make and the chip says which one is in force.

The offset for my zone looks wrong by an hour.

Check the date, not the zone. Europe/Berlin is UTC+1 in January and UTC+2 in July, so any code holding a fixed offset for it is wrong for roughly half the year. The offset shown here is computed for the instant you entered, using the rules the browser ships from the IANA time zone database, which is also why a zone name is worth storing and a raw offset usually is not.

Can it handle a timestamp with nanosecond precision?

Yes. A nanosecond epoch value is 19 digits, which is past the point where a JavaScript number stays exact — 1786613480123456789 becomes 1786613480123456800 the moment it goes through an ordinary numeric conversion. The digits are split as text here instead, so the epoch rows stay exact. The calendar rows still stop at milliseconds, because that is as fine as a date value goes.

What does the ISO week number mean?

ISO 8601 weeks run Monday to Sunday and week 1 is the week containing the year's first Thursday, so early January can legitimately belong to the previous ISO year. If a report is grouped by week and the totals are slightly off around New Year, that rule is usually the culprit.

Related tools

Specifications and references

• RFC 5322 §3.3 — Date and Time Specification – The current definition of the form still commonly called RFC 2822
• MDN — Intl.DateTimeFormat – The API behind the zoned row and its real offset