What a Unix timestamp is
A Unix timestamp counts the seconds since 1 January 1970, 00:00:00 UTC: an arbitrary starting point chosen by Unix’s designers, now used almost everywhere.
Because it’s a single number counted from a fixed instant in UTC, it carries no timezone and no daylight-saving rules. 1758024000 means the same moment in Tokyo as it does in Lisbon; only the way you display it differs.
Seconds, milliseconds, and the digits that give it away
Different systems count in different units, and the number alone doesn’t say which:
| Unit | Typical length today | Example |
|---|---|---|
| Seconds | 10 digits | 1758024000 |
| Milliseconds | 13 digits | 1758024000000 |
| Microseconds | 16 digits | 1758024000000000 |
| Nanoseconds | 19 digits | 1758024000000000000 |
Unix tools, Postgres and JWT claims use seconds. JavaScript, Java and most APIs use milliseconds. Go and some tracing systems go finer.
This page guesses from the digit count and tells you which unit it used. When the guess is wrong (a very old date in milliseconds can be short enough to look like seconds), set the unit yourself.
Why your date says 1970
It’s the most common timestamp bug there is: seconds handed to something that expects milliseconds. The value lands a few weeks after the epoch, so every record appears to be from January 1970.
The mirror image gives absurdly distant dates: milliseconds read as seconds land tens of thousands of years in the future. Both are one multiplication away from correct.
Timezones, and why the numbers still disagree
The timestamp is fixed, but people compare rendered dates. Two systems showing the same instant as 2026-09-16 12:00 and 2026-09-16 14:00 aren’t disagreeing about the timestamp; one is showing UTC and the other local time.
That’s why the list here shows both, plus an ISO 8601 form with your offset attached: the format to paste into code, because it’s unambiguous.
Daylight saving never affects the timestamp itself. It only changes how a local time maps onto it, which is why scheduled jobs and reminders are safer stored as timestamps and converted at the moment of display.
The 2038 problem
A signed 32-bit integer runs out at 03:14:07 UTC on 19 January 2038. Systems still storing timestamps that way will wrap round to 1901.
Modern languages and databases use 64-bit values, which last longer than the age of the universe, so this is now mostly a concern for old embedded devices and legacy C code, but it’s the reason you’ll occasionally see a date in 2038 used as “never expires”.
Leap seconds
Unix time ignores leap seconds: a leap second repeats the same timestamp rather than adding a new one. That keeps the arithmetic simple (every day is exactly 86,400 seconds) at the cost of being a fraction of a minute away from astronomical time. For everyday work it never matters; for precise scientific timing, it does.