guides
What is a Unix Timestamp?
How Unix timestamps work, why developers use them, common gotchas, and how to convert them in code.
What is a Unix timestamp?
A Unix timestamp (also called Unix time, POSIX time, or epoch time) is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC — a reference point known as the Unix epoch.
For example, the timestamp 1717200000 corresponds to June 1, 2024, 00:00:00 UTC.
The epoch (January 1, 1970) was chosen arbitrarily when Unix was being developed in the early 1970s. It predates most modern computing infrastructure, which made it a safe "start of time" anchor.
Why developers use Unix timestamps
- —Timezone-agnostic: A Unix timestamp is always in UTC. Converting to a local timezone happens at display time, not storage time. This eliminates ambiguity when storing, comparing, or transmitting dates across systems in different timezones.
- —Simple arithmetic: Comparing two timestamps is just subtraction. The difference between two Unix timestamps in seconds gives you the elapsed time directly. No calendar math, no daylight saving adjustments, no month-length variations.
- —Universal support: Every major programming language, database, and operating system understands Unix timestamps. It's the closest thing to a universal date format in software.
- —Compact storage: A 32-bit integer holds any date from 1901 to 2038. A 64-bit integer extends this range billions of years in either direction. Much more efficient than storing a formatted date string.
Converting timestamps in code
JavaScript
// Current timestamp (seconds)
Math.floor(Date.now() / 1000)
// Current timestamp (milliseconds)
Date.now()
// Timestamp to Date
new Date(1717200000 * 1000)
// Date to timestamp
Math.floor(new Date('2024-06-01').getTime() / 1000)Python
import time from datetime import datetime, timezone # Current timestamp int(time.time()) # Timestamp to datetime (UTC) datetime.fromtimestamp(1717200000, tz=timezone.utc) # Datetime to timestamp datetime(2024, 6, 1, tzinfo=timezone.utc).timestamp()
SQL
-- Current timestamp SELECT UNIX_TIMESTAMP(); -- MySQL SELECT EXTRACT(EPOCH FROM NOW()); -- PostgreSQL -- Timestamp to datetime FROM_UNIXTIME(1717200000) -- MySQL TO_TIMESTAMP(1717200000) -- PostgreSQL
Common gotchas
- Seconds vs. milliseconds
- Unix timestamps are defined in seconds. But JavaScript's Date.now() and many APIs return milliseconds. A timestamp of 1717200000000 (13 digits) is milliseconds; 1717200000 (10 digits) is seconds. Confusing them results in dates in 1970 or the year 56000. Always check which unit an API uses.
- The Year 2038 problem
- A signed 32-bit integer maxes out at 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. Systems storing timestamps as 32-bit integers will overflow at this point. Most modern systems use 64-bit integers, which are safe for billions of years. But legacy embedded systems and databases using 32-bit UNIX_TIMESTAMP() columns are still affected.
- Daylight saving time
- Unix timestamps are in UTC, so they are completely unaffected by daylight saving time. DST is a display-layer concern — it only matters when converting a timestamp to a local time for human reading. This is one of the biggest advantages of storing times as timestamps rather than local datetime strings.
Unix Timestamp Converter
Convert between Unix timestamps and human-readable dates instantly.
Frequently asked questions
- What does epoch mean?
- In computing, an epoch is a reference point from which time is measured. The Unix epoch is January 1, 1970, 00:00:00 UTC. Other systems use different epochs: Windows FILETIME uses January 1, 1601; GPS time uses January 6, 1980; Apple's Core Data uses January 1, 2001.
- Can Unix timestamps be negative?
- Yes. Negative Unix timestamps represent dates before January 1, 1970. For example, -86400 is December 31, 1969. Most programming languages and databases handle negative timestamps correctly, though some older libraries don't. Be careful when working with historical dates.
- Why not just store dates as strings?
- Date strings like "2024-06-01 12:00:00" are ambiguous without a timezone, can't be compared with simple integer comparison, take more storage space, and vary in format across systems (ISO 8601 vs. US format vs. others). Timestamps avoid all of these problems. Convert to strings only for display.