If you have ever seen a number like 1715251200 in an API response and wondered what it means — that is a Unix timestamp. It is one of the most universal ways to represent a moment in time in software, and every developer will encounter it eventually.
What Is a Unix Timestamp?
A Unix timestamp (also called Unix time, POSIX time, or epoch time) is the number of seconds elapsed since the Unix epoch: January 1, 1970, at 00:00:00 UTC.
So 1715251200 means 1,715,251,200 seconds have passed since midnight on January 1, 1970. Converting that gives you May 9, 2024 at 12:00:00 UTC.
The Unix epoch itself — 0 — corresponds to 1970-01-01T00:00:00Z. Negative values represent times before the epoch.
Why 1970?
The Unix operating system was developed in the late 1960s and early 1970s. When the developers needed a starting point for time tracking, they chose January 1, 1970 as a convenient round date that pre-dated the system's use but was still recent enough to avoid overflow issues on 32-bit hardware of the era.
Seconds vs Milliseconds
Here is a common source of bugs: not all systems use seconds.
| System | Unit | Example |
|---|---|---|
| Unix/POSIX, Python time.time() | Seconds | 1715251200 |
| JavaScript Date.now() | Milliseconds | 1715251200000 |
| Java System.currentTimeMillis() | Milliseconds | 1715251200000 |
JavaScript timestamps are 1,000× larger than Unix timestamps. If you store a JavaScript timestamp in a field expecting Unix time, everything downstream breaks. The quick check: if the number is 13 digits, it is milliseconds. If it is 10 digits, it is seconds (until 2286, when Unix timestamps become 11 digits).
Working With Timestamps in Code
JavaScript
``javascript
// Current timestamp in seconds
const unixNow = Math.floor(Date.now() / 1000);
// Current timestamp in milliseconds
const msNow = Date.now();
// Convert Unix timestamp (seconds) to Date object
const date = new Date(1715251200 * 1000); // multiply by 1000
console.log(date.toISOString()); // "2024-05-09T12:00:00.000Z"
// Convert Date to Unix timestamp (seconds)
const ts = Math.floor(new Date('2024-05-09T12:00:00Z').getTime() / 1000);
`
Python
`python
import time
from datetime import datetime, timezone
Current timestamp
ts = int(time.time())
Convert timestamp to datetime (UTC)
dt = datetime.fromtimestamp(1715251200, tz=timezone.utc)
print(dt.isoformat()) # 2024-05-09T12:00:00+00:00
Convert datetime to timestamp
ts = int(datetime(2024, 5, 9, 12, 0, 0, tzinfo=timezone.utc).timestamp())
`
SQL (PostgreSQL)
`sql
-- Convert Unix timestamp to timestamp
SELECT to_timestamp(1715251200);
-- Get current Unix timestamp
SELECT EXTRACT(EPOCH FROM NOW())::INTEGER;
-- Filter rows from the last 24 hours
SELECT * FROM events
WHERE created_at > EXTRACT(EPOCH FROM NOW()) - 86400;
`
The 2038 Problem
32-bit systems store Unix timestamps as signed 32-bit integers. The maximum value of a signed 32-bit integer is 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC.
After that moment, a 32-bit signed integer overflows and wraps to a large negative number — representing December 13, 1901. Any software still using 32-bit time storage will break.
Most modern systems use 64-bit integers for time, which won't overflow until the year 292,277,026,596 AD — safely beyond concern. But embedded systems, legacy databases, and old file formats may still be vulnerable.
Timestamps vs ISO 8601
Unix timestamps are great for storage and computation, but terrible for human readability. ISO 8601 (2024-05-09T12:00:00Z) is the human-readable alternative that is also machine-parseable.
The general pattern in production systems:
- Store as Unix timestamps in the database (integers are fast to index and compare)
- Transfer as ISO 8601 strings in APIs (readable, timezone-explicit)
- Display as locale-formatted strings in the UI
Timezone Awareness
Unix timestamps are always UTC. They have no timezone. When you convert a timestamp to a human-readable date, the timezone is applied at display time, not storage time.
This means:
- 1715251200
is the same moment everywhere in the world - A user in New York sees 2024-05-09 08:00:00 EDT
- A user in London sees 2024-05-09 13:00:00 BST
- The timestamp itself never changes
Never store timestamps as local times — you will lose timezone information and break comparisons across regions.
Common Calculations
`javascript
const SECOND = 1;
const MINUTE = 60;
const HOUR = 3600;
const DAY = 86400;
const WEEK = 604800;
const now = Math.floor(Date.now() / 1000);
// 30 days ago
const thirtyDaysAgo = now - (30 * DAY);
// Start of today (UTC)
const startOfDay = now - (now % DAY);
// Add 7 days
const nextWeek = now + WEEK;
`
Converting Timestamps Quickly
When you need to inspect a timestamp during debugging, the SnappyTools Unix Timestamp Converter lets you paste any Unix timestamp and instantly see the date and time in UTC and your local timezone. It also shows the relative time ("3 days ago", "in 2 hours") — useful for checking log timestamps at a glance.
Quick Reference
| Action | Value |
|---|---|
| Unix epoch | 0 = 1970-01-01T00:00:00Z |
| 1 day in seconds | 86400 |
| 1 week in seconds | 604800 |
| 30 days in seconds | 2592000 |
| Max 32-bit Unix time | 2147483647` = 2038-01-19T03:14:07Z |
| Current timestamp (10 digits) | seconds |
| Current timestamp (13 digits) | milliseconds |
Unix timestamps are simple, efficient, and universally supported. Master the conversions once and you will never be confused by a numeric date again.
Originally published at https://snappytools.app/unix-timestamp-converter/