What time is 1790550000? Unix time, milliseconds and the 2038 problem
What a Unix timestamp counts, 10 digits versus 13, why a timestamp has no time zone, leap seconds, the year 2038 problem, and how to store times in a database.
You’re halfway through an incident and the log says this:
{"event":"payment_failed","created_at":1790550000}Someone asks what time that was. The answer is 23:00 UTC on 27 September 2026, or 7 p.m. in New York. But if another service logged the same event as 1790550000000 and someone reads that as seconds, the answer lands more than 50,000 years in the future. Unix time is simple, and that’s exactly why it’s easy to get wrong.
Seconds since midnight, 1 January 1970
Unix time (epoch time) is the number of seconds since 1970-01-01 00:00:00 UTC, a moment called the epoch. Count 1,790,550,000 seconds from there and you reach 2026-09-27 23:00:00 UTC.
A single number is convenient. The gap between two moments is one subtraction, sorting is numeric sorting, and nobody has to agree on whether 09/10 means September or October. That is why operating systems, databases and most languages keep time this way internally.
Count the digits to guess the unit
The same moment in seconds and in milliseconds differs by a factor of 1,000.
| Value | Unit | In UTC |
|---|---|---|
1790550000 |
seconds (10 digits) | 2026-09-27 23:00:00 |
1790550000000 |
milliseconds (13 digits) | 2026-09-27 23:00:00 |
1790550000 misread as milliseconds |
1970-01-21 17:22:30 |
C’s time(), Python’s time.time() and the shell’s date +%s give seconds. JavaScript’s Date.now() and Java’s System.currentTimeMillis() give milliseconds. A Python backend with a JavaScript frontend is a classic place for the two to meet.
The quick check is length: around the present day, seconds have 10 digits and milliseconds 13. A date in January 1970 usually means seconds were read as milliseconds; a date tens of thousands of years out means the reverse.
The number has no time zone
1790550000 is the same instant in London, Seoul and New York. The timestamp carries no “UTC” or “Eastern Time” with it. A time zone only appears when you turn the number into a date for a person.
const d = new Date(1790550000 * 1000);
d.toISOString(); // "2026-09-27T23:00:00.000Z"
d.toLocaleString("en-US", { timeZone: "America/New_York" }); // "9/27/2026, 7:00:00 PM"So there is no such thing as “a Unix timestamp in Eastern Time”. Store a value with an offset added and it’s no longer Unix time, and before long nobody remembers which values were shifted.
Leap seconds don’t exist here
Because the Earth’s rotation isn’t perfectly regular, UTC has occasionally inserted a leap second; the last was 2016-12-31 23:59:60 UTC. POSIX, however, defines Unix time as if every day has exactly 86,400 seconds. Leap seconds aren’t counted.
Strictly speaking, then, Unix time runs 27 seconds behind the number of SI seconds that have actually elapsed since 1972. During a leap second a timestamp repeats, or systems like Google’s smear the extra second across the whole day. Most applications never notice, but if you measure precise intervals by subtracting wall-clock timestamps, it’s worth knowing.
03:14:07 UTC on 19 January 2038
Older systems stored Unix time in a signed 32-bit integer. Its largest value is 2,147,483,647, which is 2038-01-19 03:14:07 UTC. One second later the value overflows to the smallest one, −2,147,483,648, which reads as 13 December 1901.
64-bit operating systems and current languages mostly use 64-bit time, so they are clear of the limit. The remaining risk hides in less visible places: 32-bit embedded devices, old file formats, and database column types. MySQL’s TIMESTAMP type, for example, stops at 2038-01-19 03:14:07 UTC. A 30-year mortgage written today already ends past that date. 2038 isn’t a problem for the future; it’s a problem for data you save now.
Storing times in a database
The usual rule is short: store the instant in UTC, convert to the user’s zone for display.
In PostgreSQL that’s timestamp with time zone (timestamptz). Despite the name, it doesn’t store a zone. It converts the input to UTC and shows it in the session’s zone when you read it back. Put local wall-clock times into a plain timestamp and the day you move servers or get users abroad, nobody can tell which zone those values were in.
When a time travels as text, use ISO 8601 with an offset. 2026-09-27T19:00:00-04:00 and 2026-09-27T23:00:00Z are the same instant, and either one says so. A string like 2026-09-27 19:00:00 with no offset is read however the receiver pleases.
One exception: a future wall-clock time such as “every Monday at 9 a.m.” isn’t an instant. In a place with daylight saving, 9 a.m. maps to a different UTC time in summer and winter, so store the local time together with the zone name (America/New_York).
Check it now
The Unix timestamp converter turns seconds or milliseconds into dates in UTC, Seoul, Tokyo, New York and London, converts dates back to timestamps, and shows the current timestamp ticking. Try 1790550000 and 2147483647 from this article.
References
- IEEE Std 1003.1 (POSIX), Base Definitions, “Seconds Since the Epoch”
- ECMAScript specification (ECMA-262), Time Values and Time Range
- ISO 8601, Date and time — Representations for information interchange; RFC 3339
- MySQL 8.0 Reference Manual, “The DATE, DATETIME, and TIMESTAMP Types”
- PostgreSQL documentation, Date/Time Types