How to read a Unix timestamp (seconds vs ms)

The short answer. A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970. Count the digits: 10 is seconds, 13 is milliseconds, 16 is microseconds. Paste it into a converter, then add your zone's offset: India is UTC+5:30, so 1791216000 is 4:00 pm UTC and 9:30 pm IST on 5 October 2026.

The same moment has one timestamp everywhere in the world. That is the point of it: a server in Mumbai and one in Virginia write the same number for the same instant, and each reader turns it into their own local time. Almost every confusion with timestamps comes from one of two things: the unit (seconds or milliseconds), and the time zone the reader assumes.

Seconds, milliseconds or something smaller: count the digits

For any date between 2001 and 2286, the length of the number tells you the unit:

Digits	Unit	Example for 5 Oct 2026, 16:00 UTC	Who writes it
10	seconds	`1791216000`	Unix and Linux, PHP `time()`, Python `time.time()` (before the decimal point), JWT `exp` and `iat` claims, most databases
13	milliseconds	`1791216000000`	JavaScript `Date.now()`, Java `System.currentTimeMillis()`, many JSON APIs
16	microseconds	`1791216000000000`	PostgreSQL internals, some logging systems
19	nanoseconds	`1791216000000000000`	Go `time.Now().UnixNano()`, some tracing tools

The classic mistake is reading a millisecond value as seconds, which lands about 56,000 years in the future, or reading seconds as milliseconds, which lands on 21 January 1970. If a converted date is absurd, the unit is wrong, not the timestamp.

How to convert a timestamp to a date

Copy the number exactly, with no spaces or commas.
Open the Unix Timestamp Converter and paste it. The unit is detected from its size, and you can override it.
Read the result in UTC (the Z at the end of an ISO date means UTC) and in your own zone. India Standard Time is the default here; pick any other zone from the list.
To go the other way, pick a date and time and copy the timestamp in seconds or milliseconds.

By hand, if you must. Divide a seconds timestamp by 86,400, the seconds in a day. 1791216000 ÷ 86,400 = 20,731 whole days, with 57,600 seconds left over. Day 20,731 after 1 January 1970 is 5 October 2026, and 57,600 seconds is 16 hours, so the time is 16:00 UTC. In practice nobody does this by hand; every language has a one-line conversion (below).

A worked example

A log line reads ts=1791216000. It has 10 digits, so it is seconds.

In UTC: Monday, 5 October 2026, 16:00:00, written 2026-10-05T16:00:00Z.
In India (UTC+5:30, no daylight saving): 5 October 2026, 21:30:00 IST, written 2026-10-05T21:30:00+05:30.
In London on that date (British Summer Time, UTC+1): 17:00.
In New York on that date (Eastern Daylight Time, UTC−4): 12:00 noon.

If the same log had said ts=1791216000000, with 13 digits, it would be the same instant in milliseconds.

Converting in code

Language	Seconds to date	Current time in seconds
JavaScript	`new Date(1791216000 * 1000).toISOString()`	`Math.floor(Date.now() / 1000)`
Python	`datetime.fromtimestamp(1791216000, tz=timezone.utc)`	`int(time.time())`
PostgreSQL	`to_timestamp(1791216000)`	`extract(epoch from now())`
MySQL	`FROM_UNIXTIME(1791216000)`	`UNIX_TIMESTAMP()`
Linux shell	`date -u -d @1791216000`	`date +%s`
Excel	`=A1/86400 + DATE(1970,1,1)` then format as date and time	none built in

Two notes on that table. JavaScript's Date counts in milliseconds, so a seconds value must be multiplied by 1,000 first. And MySQL's FROM_UNIXTIME and Excel's formula give the time in the session's or sheet's own zone, not necessarily UTC; add + 5.5/24 in Excel to show IST from a UTC value.

Time zones and daylight saving

A timestamp has no time zone. Only the display does. When a date looks "5 hours 30 minutes off", the timestamp is almost always right and something displayed it in UTC while you expected IST, or the other way round.

India has one zone, UTC+5:30, and no daylight saving, so IST is a fixed offset all year. Many other countries shift by an hour in summer. That is why a converter should use real zone names (Asia/Kolkata, Europe/London, America/New_York) from the IANA time zone database rather than a fixed offset: the same London time is UTC+0 in January and UTC+1 in July.

Leap seconds and the year 2038

Leap seconds are ignored. The POSIX standard defines every day as exactly 86,400 seconds, so Unix time skips the 27 leap seconds added since 1972. For almost every purpose this does not matter; it only does if you are measuring intervals to the second across a leap second.

The 2038 problem. Systems that store the timestamp as a signed 32-bit integer can count only to 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the number wraps negative and reads as December 1901. Modern operating systems and languages use 64-bit time, which lasts about 292 billion years, but old embedded devices, file formats and database columns declared as 32-bit INT still carry the limit.

If it doesn't work

The date is in 1970. You treated a seconds value as milliseconds. Multiply by 1,000, or set the unit to seconds.
The date is thousands of years away, or "Invalid Date". You treated milliseconds as seconds. Divide by 1,000.
The time is 5:30 out. One side is showing UTC and the other IST. Check for a Z or a +05:30 at the end of the ISO date.
It is one hour out for a European or US time. A fixed offset was used where daylight saving applies. Use a named zone instead.
The number has a decimal point. That is seconds with a fraction, as Python's time.time() writes. The part before the point is the seconds.
A negative timestamp. That is a date before 1970, which is valid in most modern systems; −86400 is 31 December 1969.

Questions people ask

How do I know if a timestamp is in seconds or milliseconds?

Count the digits. A present-day timestamp in seconds has 10 digits, such as 1791216000, and in milliseconds it has 13, such as 1791216000000. Sixteen digits means microseconds and nineteen means nanoseconds. Read with the wrong unit, a seconds value lands in January 1970 and a milliseconds value lands tens of thousands of years ahead.

What time zone is a Unix timestamp in?

None. A Unix timestamp counts seconds from midnight UTC on 1 January 1970, so it names the same instant everywhere on Earth. A time zone only enters when the number is shown as a date. Show 1791216000 in UTC and it reads 16:00; show it in India Standard Time and it reads 21:30 the same day.

How do I convert a Unix timestamp to IST?

Convert it to UTC, then add 5 hours 30 minutes, because India Standard Time is UTC+5:30 all year with no daylight saving. For example, 1791216000 is 16:00 UTC on 5 October 2026, which is 21:30 IST. In code, use the zone name Asia/Kolkata rather than adding the offset by hand.

What is the current Unix timestamp?

A Unix timestamp grows by one every second, so the current value changes as you read. On 5 October 2026 it is a little under 1.792 billion seconds. The converter's live clock shows the exact value and can be paused and copied; in a terminal, date +%s prints it, and in JavaScript, Math.floor(Date.now() / 1000).

What happens to Unix time in 2038?

Systems that store the timestamp in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, the largest value such a number can hold, and wrap round to a date in 1901. Current operating systems and languages use 64-bit time and are not affected. Old embedded devices and 32-bit database columns still need checking.

Sources

Checked 5 Oct 2026:

The Open Group, POSIX.1-2024 (IEEE Std 1003.1-2024), Base Definitions, section 4.19 Seconds Since the Epoch ("each and every day shall be accounted for by exactly 86400 seconds")
MDN Web Docs: Date (JavaScript counts milliseconds since the epoch)
IANA: Time Zone Database (named zones such as Asia/Kolkata, with daylight-saving history)
IERS Earth Orientation Center: Bulletin C, latest (UTC−TAI = −37 s since 1 January 2017; no leap second at the end of December 2026)

How to read a Unix timestamp, in seconds or milliseconds, in your time zone