Unix Timestamp Converter

What is a Unix Timestamp?

A Unix timestamp (also called Unix time, POSIX time, or epoch time) is a system for describing a point in time. It represents the number of seconds (or milliseconds) that have elapsed since January 1, 1970, 00:00:00 UTC, known as the Unix epoch.

Unix timestamps are widely used in computing because they provide a simple, unambiguous way to represent time that:

• Is timezone-independent (always UTC)
• Is easy to compare and calculate with
• Avoids date format ambiguities
• Works across different systems and programming languages

Why Unix Timestamps Matter

• Database storage: Efficient storage and indexing of dates
• API responses: Standard format for timestamps in REST APIs
• Log files: Timestamps in system and application logs
• Cloud infrastructure: Used in AWS, Azure, GCP for resource metadata
• Distributed systems: Consistent time representation across servers
• Date calculations: Easy arithmetic operations (add/subtract seconds)

How Unix Timestamps Work

The Epoch

The Unix epoch is January 1, 1970, 00:00:00 UTC. This date was chosen as a reference point because:

• It predates most modern computing systems
• It's a clean starting point (midnight, start of year)
• It provides enough range for future dates

Seconds vs Milliseconds

Unix timestamps can be represented in two ways:

Seconds (Standard Unix Timestamp):

• Number of seconds since epoch
• Example: 1704067200 = January 1, 2024, 00:00:00 UTC
• Common in: Unix/Linux systems, databases, APIs

Milliseconds (JavaScript Timestamp):

• Number of milliseconds since epoch
• Example: 1704067200000 = January 1, 2024, 00:00:00 UTC
• Common in: JavaScript, Java, some APIs

Conversion Formula

Unix Timestamp (seconds) = (Date - Epoch) / 1000
Unix Timestamp (milliseconds) = Date - Epoch

Where:

• Epoch = January 1, 1970, 00:00:00 UTC
• Date = The date you want to convert

Common Timestamp Values

The Year 2038 Problem

On January 19, 2038 at 03:14:07 UTC, 32-bit signed integers will overflow:

• Maximum 32-bit signed integer: 2,147,483,647 seconds
• This equals: 2147483647 = January 19, 2038, 03:14:07 UTC

Systems using 32-bit timestamps will need to migrate to 64-bit before this date.

Date Format Standards

ISO 8601

The most common international standard for date and time representation:

2024-01-01T00:00:00Z
2024-01-01T00:00:00+00:00
2024-01-01T12:30:45.123Z

Format: YYYY-MM-DDTHH:mm:ss.sssZ

• YYYY: 4-digit year
• MM: 2-digit month (01-12)
• DD: 2-digit day (01-31)
• T: Separator between date and time
• HH: 2-digit hour (00-23)
• mm: 2-digit minute (00-59)
• ss: 2-digit second (00-59)
• sss: Milliseconds (optional)
• Z: UTC timezone indicator (or +HH:mm for offset)

RFC 3339

A profile of ISO 8601 used in internet protocols:

2024-01-01T00:00:00Z
2024-01-01T00:00:00+00:00

RFC 3339 is essentially ISO 8601 with some restrictions (always uses T separator, requires timezone).

RFC 2822

Email and HTTP date format:

Mon, 01 Jan 2024 00:00:00 GMT
Mon, 01 Jan 2024 00:00:00 +0000

Common Use Cases

1. API Timestamps

Most REST APIs return timestamps in ISO 8601 or Unix timestamp format:

{
  "id": 123,
  "created_at": "2024-01-01T12:00:00Z",
  "updated_at": 1704110400,
  "expires_at": "2024-12-31T23:59:59Z"
}

2. Database Storage

Storing timestamps efficiently in databases:

PostgreSQL:

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  unix_timestamp BIGINT DEFAULT EXTRACT(EPOCH FROM NOW())
);
 
-- Convert to Unix timestamp
SELECT EXTRACT(EPOCH FROM created_at) FROM events;
 
-- Convert from Unix timestamp
SELECT TO_TIMESTAMP(1704067200) FROM events;

MySQL:

-- Convert to Unix timestamp
SELECT UNIX_TIMESTAMP(created_at) FROM events;
 
-- Convert from Unix timestamp
SELECT FROM_UNIXTIME(1704067200) FROM events;

3. Log Files

System and application logs use Unix timestamps:

[1704067200] INFO: Application started
[1704067260] DEBUG: Processing request #123
[1704067320] ERROR: Connection timeout

4. Cloud Infrastructure

AWS:

{
  "InstanceId": "i-1234567890abcdef0",
  "LaunchTime": "2024-01-01T00:00:00.000Z",
  "State": {
    "Code": 16,
    "Name": "running"
  }
}

Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-01-01T00:00:00Z"
  name: my-pod

5. Cache Expiration

Using timestamps for cache TTL (Time To Live):

const cache = {
  data: { /* ... */ },
  expiresAt: Date.now() + (60 * 60 * 1000) // 1 hour from now
};
 
// Check if cache is expired
if (Date.now() > cache.expiresAt) {
  // Cache expired, refresh data
}

6. Session Management

Tracking session expiration:

const session = {
  userId: 123,
  createdAt: Math.floor(Date.now() / 1000), // Unix timestamp in seconds
  expiresAt: Math.floor(Date.now() / 1000) + (30 * 60) // 30 minutes
};
 
// Check if session is valid
if (Math.floor(Date.now() / 1000) < session.expiresAt) {
  // Session is valid
}

7. Scheduled Tasks

Cron jobs and scheduled tasks:

# Cron format: minute hour day month weekday
# Run at 2:30 AM every day
30 2 * * * /path/to/script.sh
 
# Convert to Unix timestamp for programmatic scheduling

Converting Timestamps in Different Languages

JavaScript/TypeScript

Current timestamp:

// Seconds (Unix timestamp)
Math.floor(Date.now() / 1000);
// 1704067200
 
// Milliseconds (JavaScript timestamp)
Date.now();
// 1704067200000

Convert timestamp to date:

// From seconds
const date = new Date(1704067200 * 1000);
date.toISOString(); // "2024-01-01T00:00:00.000Z"
 
// From milliseconds
const date = new Date(1704067200000);
date.toISOString(); // "2024-01-01T00:00:00.000Z"

Convert date to timestamp:

const date = new Date("2024-01-01T00:00:00Z");
 
// To seconds
Math.floor(date.getTime() / 1000); // 1704067200
 
// To milliseconds
date.getTime(); // 1704067200000

Python

Current timestamp:

import time
from datetime import datetime
 
# Seconds (Unix timestamp)
time.time()  # 1704067200.123
 
# Milliseconds
int(time.time() * 1000)  # 1704067200123

Convert timestamp to date:

from datetime import datetime
 
# From seconds
datetime.fromtimestamp(1704067200)
# datetime.datetime(2024, 1, 1, 0, 0)
 
# From milliseconds
datetime.fromtimestamp(1704067200 / 1000)
# datetime.datetime(2024, 1, 1, 0, 0)
 
# To ISO 8601
datetime.fromtimestamp(1704067200).isoformat()
# '2024-01-01T00:00:00'

Convert date to timestamp:

from datetime import datetime
 
date = datetime(2024, 1, 1, 0, 0, 0)
 
# To seconds
int(date.timestamp())  # 1704067200
 
# To milliseconds
int(date.timestamp() * 1000)  # 1704067200000

Go

Current timestamp:

import (
    "time"
)
 
// Seconds (Unix timestamp)
time.Now().Unix()  // 1704067200
 
// Milliseconds
time.Now().UnixMilli()  // 1704067200000

Convert timestamp to date:

import (
    "time"
)
 
// From seconds
time.Unix(1704067200, 0)
// time.Time{2024-01-01 00:00:00 +0000 UTC}
 
// From milliseconds
time.Unix(0, 1704067200000*1000000)
// time.Time{2024-01-01 00:00:00 +0000 UTC}

Convert date to timestamp:

import (
    "time"
)
 
date := time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC)
 
// To seconds
date.Unix()  // 1704067200
 
// To milliseconds
date.UnixMilli()  // 1704067200000

Bash/Command Line

Current timestamp:

# Seconds (Unix timestamp)
date +%s
# 1704067200
 
# Milliseconds
date +%s%3N
# 1704067200000

Convert timestamp to date:

# From seconds
date -d @1704067200
# Mon Jan  1 00:00:00 UTC 2024
 
# ISO 8601 format
date -d @1704067200 -Iseconds
# 2024-01-01T00:00:00+00:00
 
# On macOS (BSD date)
date -r 1704067200
# Mon Jan  1 00:00:00 UTC 2024

Convert date to timestamp:

# From date string
date -d "2024-01-01 00:00:00" +%s
# 1704067200
 
# On macOS
date -j -f "%Y-%m-%d %H:%M:%S" "2024-01-01 00:00:00" +%s
# 1704067200

Timezone Considerations

UTC vs Local Time

Unix timestamps are always in UTC. When converting to/from human-readable dates:

Important points:

• Unix timestamp = UTC time
• Display format can show any timezone
• Always store timestamps in UTC
• Convert to local time only for display

Examples

// Unix timestamp (always UTC)
const timestamp = 1704067200; // Jan 1, 2024, 00:00:00 UTC
 
// Convert to different timezones
const utcDate = new Date(timestamp * 1000);
utcDate.toISOString();        // "2024-01-01T00:00:00.000Z" (UTC)
utcDate.toLocaleString('en-US', { timeZone: 'America/New_York' }); // "12/31/2023, 7:00:00 PM" (EST)
utcDate.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' });       // "2024-01-01, 9:00:00 AM" (JST)

Best Practices

1. Always store in UTC: Store all timestamps in UTC in your database
2. Convert for display: Convert to user's local timezone only when displaying
3. Use ISO 8601: Include timezone information in API responses
4. Be explicit: Always specify timezone when parsing dates

Common Mistakes to Avoid

1. Confusing Seconds and Milliseconds

Wrong:

// Treating milliseconds as seconds
const date = new Date(1704067200000); // This is correct
const wrongDate = new Date(1704067200); // Wrong! Missing * 1000

Correct:

// Always check the magnitude
const timestamp = 1704067200;
const date = timestamp < 1e12 
  ? new Date(timestamp * 1000)  // seconds
  : new Date(timestamp);         // milliseconds

2. Timezone Confusion

Wrong:

// Assuming local timezone
const date = new Date("2024-01-01"); // May be interpreted as local midnight

Correct:

// Explicit UTC
const date = new Date("2024-01-01T00:00:00Z"); // Explicitly UTC

3. Not Handling Invalid Dates

Wrong:

const date = new Date(invalidInput);
// date might be Invalid Date, but code continues

Correct:

const date = new Date(input);
if (isNaN(date.getTime())) {
  throw new Error("Invalid date");
}

4. Precision Loss

Wrong:

// Losing milliseconds
const timestamp = Math.floor(date.getTime() / 1000); // OK if you want seconds
const backToDate = new Date(timestamp * 1000); // Lost milliseconds

Correct:

// Preserve precision when needed
const timestampMs = date.getTime(); // Keep milliseconds
const timestampS = Math.floor(date.getTime() / 1000); // Only if you need seconds

5. Year 2038 Problem

Wrong:

// 32-bit integer (will overflow in 2038)
int timestamp = time(NULL);

Correct:

// 64-bit integer (good until year 292 billion)
long long timestamp = time(NULL);

Real-World Examples

Example 1: API Rate Limiting

Using timestamps to implement rate limiting:

const rateLimiter = {
  requests: [],
  limit: 100,
  window: 60, // 60 seconds
  
  checkLimit() {
    const now = Math.floor(Date.now() / 1000);
    // Remove requests older than window
    this.requests = this.requests.filter(t => now - t < this.window);
    
    if (this.requests.length >= this.limit) {
      return false; // Rate limit exceeded
    }
    
    this.requests.push(now);
    return true;
  }
};

Example 2: Log Analysis

Parsing log files with Unix timestamps:

# Find logs from last hour
CURRENT=$(date +%s)
HOUR_AGO=$((CURRENT - 3600))
 
# Filter logs
awk -v since=$HOUR_AGO '$1 > since {print}' /var/log/app.log

Example 3: Database Query

Querying records by timestamp range:

-- PostgreSQL: Find records from last 24 hours
SELECT * FROM events
WHERE created_at > NOW() - INTERVAL '24 hours';
 
-- Using Unix timestamp
SELECT * FROM events
WHERE EXTRACT(EPOCH FROM created_at) > EXTRACT(EPOCH FROM NOW()) - 86400;

Example 4: Cache Invalidation

Implementing cache with expiration:

import time
 
cache = {
    'data': {'key': 'value'},
    'expires_at': int(time.time()) + 3600  # 1 hour from now
}
 
def get_cached_data():
    if time.time() > cache['expires_at']:
        # Cache expired, refresh
        cache['data'] = fetch_fresh_data()
        cache['expires_at'] = int(time.time()) + 3600
    return cache['data']

Frequently Asked Questions

What's the difference between Unix timestamp and JavaScript timestamp?

• Unix timestamp: Seconds since epoch (e.g., 1704067200)
• JavaScript timestamp: Milliseconds since epoch (e.g., 1704067200000)

JavaScript timestamps are 1000x larger because they include milliseconds.

Can Unix timestamps be negative?

Yes. Negative timestamps represent dates before January 1, 1970. However, many systems don't support negative timestamps, and they're rarely used in practice.

What's the maximum Unix timestamp?

For 64-bit signed integers:

• Maximum: 9,223,372,036,854,775,807 seconds
• This equals: Year 292,277,026,596 (far beyond practical use)

For 32-bit signed integers:

• Maximum: 2,147,483,647 seconds
• This equals: January 19, 2038, 03:14:07 UTC (Year 2038 Problem)

How do I handle leap seconds?

Leap seconds are not represented in Unix timestamps. Unix time assumes exactly 86,400 seconds per day. Leap seconds are handled by the system clock, not in timestamp calculations.

What timezone are Unix timestamps in?

Unix timestamps are always in UTC. They represent a specific moment in time, independent of timezone. When you convert a timestamp to a date, you can display it in any timezone.

How do I convert between seconds and milliseconds?

// Seconds to milliseconds
const ms = seconds * 1000;
 
// Milliseconds to seconds
const s = Math.floor(milliseconds / 1000);

Can I use Unix timestamps for dates before 1970?

Technically yes (negative timestamps), but:

• Many systems don't support negative timestamps
• Date libraries may have issues
• Not recommended for production use

How precise are Unix timestamps?

• Seconds: Precise to 1 second
• Milliseconds: Precise to 1 millisecond
• Microseconds: Some systems support microsecond precision

For most applications, second or millisecond precision is sufficient.

What format should I use in APIs?

Recommended: ISO 8601 format with timezone:

"2024-01-01T00:00:00Z"
"2024-01-01T12:30:45.123Z"

Alternative: Unix timestamp in seconds:

1704067200

Avoid ambiguous formats like "01/01/2024" (could be Jan 1 or Dec 1 depending on locale).

Additional Resources

• Unix Time on Wikipedia
• ISO 8601 Standard
• RFC 3339 - Date and Time on the Internet
• RFC 2822 - Internet Message Format
• Year 2038 Problem
• MDN Web Docs - Date
• Python datetime Documentation
• Go time Package