Unix Timestamp Converter

About Unix Timestamp Converter

How Does Unix Time Work?

When Ken Thompson and Dennis Ritchie created Unix at Bell Labs in 1969, they needed a simple way to represent points in time. Rather than storing dates as complex combinations of year, month, day, hour, minute, and second, they chose a single integer counting seconds from a fixed starting point. They picked midnight on January 1, 1970 UTC as that starting point because it was a convenient, recent round date at the time of development. The idea was simple - every moment in time maps to one number, and that number is the same regardless of timezone or locale.

Worked example: The timestamp 1713139200 represents April 15, 2024 at 00:00:00 UTC. To arrive at that: from January 1, 1970 to April 15, 2024 is 19,828 days. Multiply by 86,400 seconds per day and you get 1,713,139,200. To go the other direction, take any timestamp, divide by 86,400, and you get the number of days since the epoch - then convert that to a calendar date accounting for leap years.

Unix timestamps are timezone-independent. The number 1700000000 means the same instant worldwide - it is only the human-readable representation that changes depending on your timezone. This makes timestamps ideal for storing and comparing times across distributed systems.

Notable Timestamp Milestones

Timestamp	Date (UTC)	Significance
0	January 1, 1970 00:00:00	The Unix epoch - the starting point for all Unix time
86,400	January 2, 1970 00:00:00	Exactly one day after the epoch
946,684,800	January 1, 2000 00:00:00	Start of the year 2000 (Y2K)
1,000,000,000	September 9, 2001 01:46:40	The "Unix billennium" - celebrated with parties in the developer community
1,234,567,890	February 13, 2009 23:31:30	Sequential-digit timestamp - Google marked it with a Doodle
1,700,000,000	November 14, 2023 22:13:20	The 1.7 billionth second
2,000,000,000	May 18, 2033 03:33:20	The two-billionth second (upcoming)
2,147,483,647	January 19, 2038 03:14:07	Maximum signed 32-bit integer - the Year 2038 limit

Seconds vs Milliseconds

The biggest source of confusion with timestamps is the difference between seconds and milliseconds. A standard Unix timestamp counts seconds and is 10 digits long. JavaScript, Java, and some other platforms use milliseconds (13 digits) instead. Mixing up the two is a common bug - a seconds timestamp used where milliseconds are expected will produce a date in January 1970, and a milliseconds timestamp used as seconds will produce a date thousands of years in the future.

Format	Digits	Example	Used By
Seconds	10	1700000000	Unix/Linux, Python, PHP, MySQL, PostgreSQL, most REST APIs
Milliseconds	13	1700000000000	JavaScript (Date.now()), Java (System.currentTimeMillis()), Elasticsearch
Microseconds	16	1700000000000000	Python (time.time_ns() / 1000), some database systems
Nanoseconds	19	1700000000000000000	Go (time.Now().UnixNano()), high-precision logging

This tool auto-detects seconds vs milliseconds based on the number of digits. You can also toggle the format manually if the auto-detection does not match your data.

Getting and Converting Timestamps in Code

Every major programming language has built-in support for Unix timestamps. Here is how to get the current time and convert between timestamps and human-readable dates:

Language	Current Timestamp (seconds)	Current Timestamp (ms)
JavaScript	Math.floor(Date.now() / 1000)	Date.now()
Python	import time; int(time.time())	int(time.time() * 1000)
PHP	time()	round(microtime(true) * 1000)
Ruby	Time.now.to_i	(Time.now.to_f * 1000).to_i
Java	System.currentTimeMillis() / 1000	System.currentTimeMillis()
Go	time.Now().Unix()	time.Now().UnixMilli()
C#	DateTimeOffset.UtcNow.ToUnixTimeSeconds()	DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()
Bash	date +%s	date +%s%3N
SQL (PostgreSQL)	EXTRACT(EPOCH FROM NOW())	EXTRACT(EPOCH FROM NOW()) * 1000

To convert a timestamp back to a readable date string:

Language	Timestamp to Date String
JavaScript	new Date(1700000000 * 1000).toISOString()
Python	datetime.fromtimestamp(1700000000, tz=timezone.utc)
PHP	date('Y-m-d H:i:s', 1700000000)
SQL (PostgreSQL)	TO_TIMESTAMP(1700000000)
SQL (MySQL)	FROM_UNIXTIME(1700000000)

Unix Timestamps vs ISO 8601

The two most common time formats in software are Unix timestamps and ISO 8601 strings (like 2024-04-15T12:00:00Z). Each has strengths, and many production systems use both - storing timestamps internally for performance and exposing ISO 8601 externally for readability.

Feature	Unix Timestamp	ISO 8601
Format	Integer (1700000000)	String (2023-11-14T22:13:20Z)
Human-readable	No - requires conversion	Yes - readable at a glance
Timezone	Always UTC by definition	Can include timezone offset
Storage size	4-8 bytes (integer)	20-25 bytes (string)
Sorting/comparison	Fast integer comparison	String comparison (also works)
Arithmetic	Easy - just add/subtract seconds	Requires date parsing first
Best for	Databases, APIs, internal storage	Logs, user interfaces, data exchange

How Unix Time Handles Leap Seconds

One detail that surprises many developers is that Unix time does not count leap seconds. In Unix time, every day is exactly 86,400 seconds long - no exceptions. In reality, UTC occasionally inserts a leap second to keep atomic clocks synchronised with Earth's rotation. Since 1972, 27 leap seconds have been added, making International Atomic Time (TAI) currently 37 seconds ahead of UTC (International Earth Rotation and Reference Systems Service). When a leap second occurs, Unix time effectively repeats the same second value - most systems just skip it or smear it across adjacent seconds. In November 2022, the General Conference on Weights and Measures (CGPM) voted to abolish leap seconds by 2035, which will eventually simplify things for everyone.

The Year 2038 Problem

Systems that store Unix timestamps as a signed 32-bit integer can only represent values up to 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. After that, the number overflows to a negative value, causing the date to wrap back to December 13, 1901. This is often called the "Epochalypse" and is similar to Y2K but affects binary storage rather than display format.

Storage Type	Maximum Timestamp	Maximum Date
Signed 32-bit integer	2,147,483,647	January 19, 2038
Unsigned 32-bit integer	4,294,967,295	February 7, 2106
Signed 64-bit integer	9,223,372,036,854,775,807	~292 billion years from now

Most modern operating systems and programming languages already use 64-bit timestamps, which effectively eliminates the problem. The biggest risk areas are embedded systems and IoT devices (smart home hardware, industrial sensors, automotive firmware), legacy databases using MySQL's TIMESTAMP type (limited to 2038 - use DATETIME instead), and older 32-bit Android and iOS devices. Modern file systems like ZFS, NTFS, and ReFS use 64-bit timestamps, but older formats like ext2 and ext3 remain vulnerable.

Where Do Unix Timestamps Appear?

Timestamps show up in more places than most people realise. If you work with APIs, databases, or log files, you will encounter them regularly.

Context	Example	Format
JWT tokens (exp, iat, nbf claims)	{"exp": 1700000000}	Seconds
REST API responses	"created_at": 1700000000	Seconds or milliseconds (varies by API)
Server logs (Apache, Nginx)	[1700000000] Request received	Seconds
Database columns	TIMESTAMP or INTEGER	Seconds (MySQL, PostgreSQL)
Cron schedulers	Next run: 1700000000	Seconds
File metadata (mtime, ctime)	stat: Modify: 1700000000	Seconds
Git commits	author-date: 1700000000 +0000	Seconds with timezone offset
OAuth tokens	"expires_at": 1700003600	Seconds

Common Mistakes When Working with Timestamps

A few pitfalls come up again and again:

Mixing seconds and milliseconds - The most frequent bug. JavaScript's Date constructor expects milliseconds, so new Date(1700000000) gives January 20, 1970 (not November 2023). You need new Date(1700000000 * 1000). If your date lands in the 1970s when it should not, this is almost certainly the problem.

Assuming local timezone - Timestamps are always UTC. If you create a Date object from a timestamp and display it without specifying a timezone, you will get the user's local time, which can differ by up to 12 hours from what you expected. Always be explicit about UTC vs local when displaying dates.

Using 32-bit storage for future dates - If your application schedules events or generates expiry dates beyond 2038, a 32-bit integer column will silently overflow. Use BIGINT or DATETIME in your database schema.

Forgetting negative timestamps - Dates before January 1, 1970 have negative timestamps. December 31, 1969 23:59:59 UTC is -1. Not all systems handle negative timestamps correctly, so test if your application needs to work with dates before 1970.

String parsing timezone traps - Parsing a date string like "2024-04-15" without a timezone usually defaults to local time in some languages and UTC in others. JavaScript's new Date("2024-04-15") treats it as UTC, but new Date("2024-04-15T00:00:00") treats it as local time. Always include a timezone offset or use UTC explicitly to avoid off-by-one-day errors near midnight.

For converting between time zones, the Time Zone Converter handles any IANA timezone. For inspecting JWT token timestamps, the JWT Decoder extracts and displays all claims including expiry dates. For scheduling recurring jobs with cron syntax, see the Cron Expression Builder. All conversions on this page run entirely in your browser using the JavaScript Date API.

Sources

• POSIX.1-2017 - Seconds Since the Epoch definition
• RFC 3339 - Date and Time on the Internet: Timestamps
• ISO 8601 - Date and time format standard
• MDN - JavaScript Date object reference
• IANA Time Zone Database
• Wikipedia - Year 2038 problem