About Unix Timestamps
A Unix timestamp (also known as Epoch time or POSIX time) is a system for tracking time as a running count of seconds. It measures time by the number of seconds that have elapsed since the Unix Epoch: 00:00:00 UTC on January 1, 1970 (Thursday), minus leap seconds.
Why Use Unix Timestamps?
Unix timestamps are widely used in programming and computing because they:
- Universal: Independent of time zones and locale settings
- Simple: Just a single integer representing a point in time
- Sortable: Chronological order matches numerical order
- Compact: Efficient storage compared to string dates
- Calculable: Easy to perform date arithmetic
- Standardized: Used across all programming languages and platforms
Seconds vs Milliseconds
Unix Timestamp in Seconds
The standard Unix timestamp uses seconds. A timestamp in seconds typically has 10 digits (until the year 2286). For example: 1609459200 represents January 1, 2021.
Unix Timestamp in Milliseconds
JavaScript and some other languages use milliseconds for greater precision. A millisecond timestamp typically has 13 digits. For example: 1609459200000 represents the same date with millisecond precision.
Conversion: Multiply seconds by 1,000 to get milliseconds, or divide milliseconds by 1,000 to get seconds.
Common Date Formats
ISO 8601
International standard format: YYYY-MM-DDTHH:mm:ss.sssZ
Example: 2021-01-01T00:00:00.000Z
The "Z" indicates UTC (Zulu time zone).
RFC 2822
Email and HTTP header format: Day, DD Mon YYYY HH:mm:ss TZ
Example: Fri, 01 Jan 2021 00:00:00 GMT
UTC (Coordinated Universal Time)
Human-readable format showing time in UTC timezone.
Example: Fri, 01 Jan 2021 00:00:00 GMT
Local Date/Time
Displays date and time according to the user's system locale and timezone settings.
Important Timestamps in History
- 0 - Unix Epoch (January 1, 1970, 00:00:00 UTC)
- 946684800 - Y2K (January 1, 2000, 00:00:00 UTC)
- 1000000000 - 1 billion seconds (September 9, 2001)
- 1234567890 - February 13, 2009, 23:31:30 UTC
- 2147483647 - Year 2038 problem (maximum 32-bit signed integer)
The Year 2038 Problem
On January 19, 2038, at 03:14:07 UTC, 32-bit systems will encounter an integer overflow similar to the Y2K problem. The timestamp will reach 2,147,483,647 (maximum value for a 32-bit signed integer) and wrap around to negative values. Modern 64-bit systems are not affected by this issue.
Time Zones and UTC
Unix timestamps always represent UTC time. When displaying timestamps to users, they're typically converted to the local timezone. This is why the same timestamp can show different local times depending on where you are in the world.
For example, the timestamp 1609459200 represents:
- 00:00:00 on January 1, 2021 in UTC
- 19:00:00 on December 31, 2020 in EST (UTC-5)
- 01:00:00 on January 1, 2021 in CET (UTC+1)
Use Cases
- Databases: Storing dates in a timezone-independent format
- APIs: Exchanging date/time information between systems
- Logging: Recording when events occurred
- Caching: Setting expiration times
- Authentication: Token expiration, session management
- Scheduling: Cron jobs, task scheduling
- Analytics: Time-series data analysis
Programming Examples
JavaScript
// Get current timestamp in seconds
Math.floor(Date.now() / 1000)
// Get current timestamp in milliseconds
Date.now()
// Convert timestamp to Date object
new Date(1609459200 * 1000)
// Convert Date to timestamp
Math.floor(new Date().getTime() / 1000)Python
import time
from datetime import datetime
# Get current timestamp
int(time.time())
# Convert timestamp to datetime
datetime.fromtimestamp(1609459200)
# Convert datetime to timestamp
int(datetime.now().timestamp())PHP
// Get current timestamp
time()
// Convert timestamp to date
date('Y-m-d H:i:s', 1609459200)
// Convert date to timestamp
strtotime('2021-01-01 00:00:00')Best Practices
- Always store dates as Unix timestamps in databases for consistency
- Convert to human-readable format only when displaying to users
- Use UTC for all server-side operations
- Convert to local time zones only on the client side
- Be aware of the seconds vs milliseconds difference in your language/framework
- Consider using 64-bit integers to avoid the Year 2038 problem
- Document which unit (seconds or milliseconds) your API uses