Unix Timestamps Explained: Seconds vs Milliseconds, Time Zones and the Year 2038

The short answer

A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It has no time zone: the same timestamp is the same instant everywhere in the world, and only its display changes by zone. A 10-digit timestamp is usually in seconds; a 13-digit one is usually in milliseconds. The free Unix Timestamp Converter converts either way and shows the result in several time zones at once.

Seconds or milliseconds?

This is the most common source of timestamp bugs.

Digits	Unit	Example	Typical source
10	Seconds	1760140800	Unix tools, PHP, Python time.time(), most APIs
13	Milliseconds	1760140800000	JavaScript Date.now(), Java, many databases
16	Microseconds	1760140800000000	Some databases and logging systems

If you feed a seconds value into something expecting milliseconds, you get a date in January 1970. Feed milliseconds into something expecting seconds and you get a date tens of thousands of years in the future. The converter has an ms / s switch so you can check which unit a value is in.

Converting a timestamp to a date

In the converter, paste the timestamp, choose ms or s, and you'll see:

• ISO 8601 form, for example 2025-10-11T00:00:00.000Z. The Z means UTC.
• Relative time, such as "3d ago" or "2h from now".
• The same instant in nine zones: your local time, UTC, India, New York, Los Angeles, London, Dubai, Singapore and Tokyo.

"Use current time" fills in the timestamp for right now.

Converting a date to a timestamp

Pick a date and time in the date picker and click Convert. The picker uses your browser's local time zone, so a date entered on a laptop set to India time produces the timestamp for that time in IST. If you need the timestamp for a UTC time, either set the picker to the equivalent local time or remember the offset (IST is UTC+5:30).

In code

JavaScript

Math.floor(Date.now() / 1000) gives seconds. new Date(1760140800 * 1000) turns seconds into a Date; note the × 1000.

Python

int(time.time()) gives seconds. datetime.fromtimestamp(ts, tz=timezone.utc) converts with an explicit zone; without tz, Python uses the machine's local zone.

SQL (PostgreSQL)

to_timestamp(1760140800) returns a timestamp with time zone. extract(epoch from now()) goes the other way.

Shell

date +%s prints the current timestamp. On Linux, date -d @1760140800 prints the date.

Time zones: store UTC, display local

Timestamps avoid time zone confusion only if you keep them as timestamps (or UTC) until the moment you display them. Common mistakes:

• Converting to local time on the server, then again in the browser, shifting the time twice.
• Storing local time without a zone. "2026-10-11 09:00" means different instants in Delhi and London.
• Daylight saving time. India doesn't use DST, but the US and Europe do. A meeting at "9:00 New York time" is 14:00 UTC in winter and 13:00 UTC in summer. Converting via a timestamp handles this correctly; adding a fixed offset doesn't.

Leap seconds

Unix time ignores leap seconds: every day is treated as exactly 86,400 seconds. For almost all application work this doesn't matter. It matters only if you need sub-second accuracy across a leap second, which is rare outside scientific and financial systems.

The year 2038 problem

Systems that store Unix time as a signed 32-bit integer can count only up to 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later the value overflows to a negative number, which reads as 1901.

Most modern systems use 64-bit time, which pushes the limit billions of years away. The risk is in older embedded devices, old database columns defined as 32-bit integers, and file formats with fixed 32-bit fields. If you design a schema today, use a 64-bit type (BIGINT) or a native timestamp type.

Negative timestamps

Dates before 1970 are negative. −86,400 is 31 December 1969. Most languages handle these, but some older tools and spreadsheets don't, so test if you work with historical dates.

Other date formats you'll meet

Format	Example	Where
ISO 8601	2026-10-11T09:30:00Z	APIs, JSON, databases
ISO 8601 with offset	2026-10-11T15:00:00+05:30	Logs and APIs that keep local time
RFC 2822	Sun, 11 Oct 2026 09:30:00 +0000	Email headers, RSS
Excel serial date	46306	Spreadsheets

Converting Excel dates. Excel stores dates as days since 1900 (with a historical quirk). For dates after March 1900, the conversion is: Unix seconds = (Excel serial − 25569) × 86400. 25569 is the Excel serial number for 1 January 1970. Excel serials are usually in the spreadsheet's local time, not UTC, so check the offset.

Debugging with timestamps

Timestamps make log investigation much easier:

• Order events across systems. If two services log Unix time, you can merge their logs and sort numerically, even when the servers are in different zones.
• Measure durations. Subtract two timestamps: 1760141400 − 1760140800 = 600 seconds, or 10 minutes.
• Spot clock skew. If a request appears to finish before it started, one machine's clock is off. Servers should sync time with NTP.
• Check token expiry. A JWT's exp claim is a timestamp in seconds. Compare it with the current timestamp to see whether a token has expired.

Quick reference

Event	Timestamp (seconds)
Unix epoch	0
1 billion seconds	1000000000 (9 Sep 2001, 01:46:40 UTC)
32-bit limit	2147483647 (19 Jan 2038, 03:14:07 UTC)

Related developer tools

• JSON Formatter to read API responses that contain timestamps
• JWT Decoder: the exp and iat claims in a JWT are Unix timestamps in seconds
• Timezone Converter for scheduling across zones