How to convert epoch time
- Paste an epoch value into the timestamp field, or press Use current time.
- Let the unit be detected, or force seconds or milliseconds with the buttons.
- To go the other way, pick a date and time and press Convert date.
- Compare the ISO, local and UTC forms. They are the same moment written differently.
- Copy every representation at once with the copy button.
What you get from one value
- Epoch seconds and milliseconds side by side, so you can supply whichever a system wants.
- ISO 8601 in UTC, the format APIs and data interchange expect.
- Local time in your own zone, plus the zone name so there is no ambiguity.
- The RFC-style UTC string used in HTTP headers.
- A relative description such as 'three days ago'.
- The day of the week, which raw timestamps hide completely.
Why the epoch is 1970
There is no cosmic significance to it. When Unix was being developed at Bell Labs around 1970, the engineers needed a zero point for a counter and picked the start of a convenient nearby year. Everything since has inherited that choice, which is why a number like 1700000000 means something to every computer on the planet.
It is not the only epoch in use. Windows file times count 100-nanosecond intervals from 1601. Some databases count days from 1900. GPS counts weeks and seconds from 1980. When a converted date is decades out from what you expected, a different epoch is usually the reason.
The unit trap
Epoch values come in seconds, milliseconds, microseconds and occasionally nanoseconds, and nothing about the number announces which. A ten-digit value is seconds, thirteen is milliseconds, sixteen is microseconds. That heuristic holds for any date in the current era and is what this converter uses.
The failure mode is memorable. Feed milliseconds into something expecting seconds and you get a date around the year 55,000. Feed seconds into something expecting milliseconds and you get a moment in January 1970. Both are obviously wrong, which is fortunate.
Negative timestamps
Dates before 1970 are negative. That is perfectly valid arithmetic, and plenty of systems reject them anyway, an unsigned integer column cannot store one, and some libraries return an error rather than a date. If you are handling historical dates, birth dates in particular, check that every layer of your stack accepts negatives before relying on it.
Things epoch time deliberately ignores
- Leap seconds. Unix time assumes every day is exactly 86,400 seconds, so leap seconds are skipped rather than counted.
- Time zones. An epoch value is an instant. The zone appears only when you format it.
- Calendars. Months and years are display concepts. The counter simply increments.
This is a strength, not a shortcoming. All the messy human parts of timekeeping are pushed to the edge of the system where they belong, and everything internal compares two integers.
Storing time sensibly
Store instants as epoch values or as UTC, and convert to local time only when displaying. Store future appointments with a fixed local time as a date plus a time zone identifier instead, because zone rules change and an instant would drift.
Use 64-bit storage. The 32-bit signed limit overflows on 19 January 2038, and while most systems have moved on, embedded devices and old database schemas have not. For converting the other way from a chosen date, the timestamp converter is the companion tool, and the date calculator handles intervals. Nothing is uploaded at any stage.
Comparing epoch values
Because an epoch value is a plain integer, comparing two moments is ordinary arithmetic. Subtract one from the other and the result is a duration in seconds, 3600 is an hour, 86400 a day. That simplicity is why epoch time is used internally even in systems that display something friendlier.
The trap is comparing values in different units. A timestamp in seconds and one in milliseconds differ by a factor of a thousand, so subtracting them produces a duration that is nonsense but not obviously nonsense. Normalise to one unit before any arithmetic, and prefer milliseconds internally if the system mixes both, since dividing down loses less than multiplying up invents.