Unix Timestamps Explained: Seconds, Milliseconds, UTC and IST

What a Unix timestamp is

A Unix timestamp is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. Because it is a single number, it is easy to store, compare and sort, and it means the same thing in every time zone. That is why databases, APIs, log files and JWT tokens use it so often.

For example, 1700000000 is 22 November 2023, 22:13:20 UTC.

Seconds or milliseconds?

Some systems count seconds and others count milliseconds. Unix tools, many databases and JWT claims such as exp and iat use seconds. JavaScript, Java and many web APIs use milliseconds. The quickest check is the length. A current timestamp in seconds has 10 digits, such as 1700000000, and one in milliseconds has 13 digits, such as 1700000000000.

If a converted date lands in January 1970, you passed seconds where milliseconds were expected. If it lands tens of thousands of years in the future, you passed milliseconds where seconds were expected. The Timestamp Converter treats small numbers as seconds and large numbers as milliseconds, then shows both values.

Converting to a readable date

Paste the number into the converter and it shows the same moment as an ISO 8601 date in UTC, as a UTC string, in your own local time zone, and as a relative phrase such as 3 days ago. You can also go the other way by typing a date such as 2024-05-01T10:30:00Z and reading the Unix value.

In code, JavaScript uses new Date(seconds * 1000) and date.getTime() for milliseconds. Python uses datetime.fromtimestamp(seconds, tz=timezone.utc) and time.time(). On Linux, date -d @1700000000 prints the date.

UTC and IST

India Standard Time is UTC plus 5 hours 30 minutes, with no daylight saving. To get IST from a UTC time, add 5:30. So 10:30 UTC is 16:00 IST. The timestamp itself does not change between the two. Only the way the moment is written changes.

The converter shows the local time using the time zone of your browser, so if your device is set to India it will show IST directly.

Common mistakes

Most timestamp bugs come from time zones and units rather than the number itself.

• Storing local time instead of UTC. Two servers in different zones then disagree about the same event.
• Parsing a date string with no zone, such as 2024-05-01 10:30. Different parsers treat it as local time or as UTC, so the result can shift by hours.
• Mixing seconds and milliseconds between a frontend and a backend.
• Using a 32-bit integer. A signed 32-bit timestamp runs out on 19 January 2038, so use 64-bit values for dates far in the future.

A good habit

Store and transmit times as UTC timestamps or ISO 8601 strings that end in Z, and convert to a local zone only when you show a time to a person. When something looks wrong in a log, paste the raw number into a converter first. It tells you in a few seconds whether the problem is the value, the unit or the zone.