A Unix timestamp is a single integer: the number of seconds elapsed since 1 January 1970 at 00:00:00 UTC, known as the epoch. It has no timezone, no daylight saving, no locale and no ambiguity, which is exactly why it is the standard way to store an instant in almost every database and API. Formatting it for a human is a separate, later step.
Take 1700000000. Dividing by 86,400 seconds per day gives 19,675 whole days with 80,000 seconds left over. Counting 19,675 days from the epoch — 53 years plus 13 leap days — lands on 14 November 2023, and 80,000 seconds is 22 hours, 13 minutes and 20 seconds.
So 1700000000 is Tuesday 14 November 2023, 22:13:20 UTC. In New York, five hours behind at that time of year, the same instant is 17:13:20 on the same day. In Karachi, five hours ahead, it is 03:13:20 on 15 November — a different calendar date for the identical moment. The timestamp is unchanged; only its presentation differs.
The most frequent bug in date handling. JavaScript Date.now() returns milliseconds; most other languages and Unix tools return seconds. The two differ by a factor of a thousand, and you can tell them apart instantly by length:
| Digits | Unit | Example | Interpreted as seconds |
|---|---|---|---|
| 10 | Seconds | 1700000000 | 2023 — correct |
| 13 | Milliseconds | 1700000000000 | Year 55,845 — obviously wrong |
| 16 | Microseconds | 1700000000000000 | Far future nonsense |
The two failure signatures are easy to recognise once you know them. A millisecond value read as seconds gives a date tens of thousands of years away. A second value read as milliseconds gives a date in January 1970 — if a bug report says a record was created on 20 January 1970, someone divided by a thousand too many times.
Since 1972, 27 leap seconds have been inserted into UTC to keep clocks aligned with the Earth rotation. Unix time pretends they never happened: every day is exactly 86,400 seconds. This makes date arithmetic simple and reliable, at the cost of being about 27 seconds away from a true count of elapsed physical seconds since 1970.
The practical consequence is that a leap second either repeats a timestamp value or is smeared across a longer interval, depending on the system. Google, Amazon and others use a smear that slows clocks slightly over several hours rather than repeating a second. For nearly all applications this is invisible. For financial ordering, distributed consensus or scientific timing, it matters, and TAI or a monotonic clock is the correct tool instead.
Systems that store the timestamp as a signed 32-bit integer can count no higher than 2,147,483,647. That value arrives at 03:14:07 UTC on 19 January 2038. One second later the integer overflows to its most negative value, and the date reads as 13 December 1901.
Modern platforms use 64-bit time and are safe for roughly 292 billion years. The exposure is in embedded devices, older filesystems, some database column types, and any code that casts a timestamp to a 32-bit int. It also bites today, not in 2038: a 30-year mortgage term, a certificate expiry, or a far-future scheduling date can already overflow on affected systems. If you are storing dates beyond 2038, confirm the column width.
For logs, APIs and anything exchanged between systems, ISO 8601 is the format worth insisting on: 2023-11-14T22:13:20Z, where the trailing Z means UTC. Its virtues are that it sorts correctly as plain text, it is unambiguous about the order of year, month and day, and it carries the offset explicitly.
The formats to avoid are the locale-dependent ones. 11/14/2023 and 14/11/2023 are the same date written two ways, and 03/04/2023 is genuinely undecidable without knowing the writer country. A timestamp with no offset at all is worse still, because whoever reads it will assume their own timezone.
Yes. Negative values represent instants before 1970 — −86400 is 31 December 1969. Some libraries and databases handle them poorly, so historical dates are often better stored as a date type than as an epoch integer.
Almost always a daylight-saving conversion applied somewhere in the chain. The timestamp itself never shifts; a formatting step converted it to a local zone. Store UTC, convert only at the point of display.
Store an instant as UTC — an epoch integer or a timestamptz column. But a calendar value such as a birthday or a public holiday is not an instant and should be stored as a plain date, or it will drift across timezones.
No. The conversion is arithmetic performed in your browser, and nothing you paste is transmitted or logged.
Every tool comes with a written guide, and every category is one click away.