Timestamp Formats Compared

Introduction

In software development, representing time is more complex than it might seem. Different systems, protocols, and use cases require different timestamp formats. Choosing the right format can mean the difference between a robust, interoperable system and one plagued by timezone bugs, parsing errors, and data corruption.

This guide examines the most common timestamp formats, their strengths and weaknesses, and provides practical guidance on when to use each one.

Unix Timestamp (Epoch Time)

The Unix timestamp is the number of seconds elapsed since the Unix epoch: January 1, 1970, 00:00:00 UTC.

Characteristics

• Format: Integer (32-bit or 64-bit)
• Precision: Seconds (standard), milliseconds, or microseconds in variants
• Timezone: Always UTC (implicit)
• Range (32-bit): 1901-12-13 to 2038-01-19
• Range (64-bit): Practically unlimited (billions of years)

Pros

• Extremely compact: 4 bytes (32-bit) or 8 bytes (64-bit)
• Simple arithmetic: easy to calculate time differences
• Fast sorting and indexing in databases
• No timezone ambiguity
• Universal support across programming languages

Cons

• Not human-readable
• 32-bit version faces Y2038 problem
• No built-in timezone information
• Standard format lacks sub-second precision

When to Use

Unix timestamps are ideal for:

• Database storage (compact and efficient)
• API responses where bandwidth matters
• System logs and event timestamps
• Cache expiration and TTL calculations
• Cross-platform data exchange
• Authentication tokens -- JWT claims (exp, iat, nbf) use seconds-precision Unix timestamps. See our JWT Decoder to inspect these claims.

ISO 8601

ISO 8601 is an international standard for representing dates and times in a human-readable, machine-parseable format.

Characteristics

• Format: String (YYYY-MM-DDTHH:MM:SS)
• Precision: Seconds, milliseconds, microseconds, or nanoseconds
• Timezone: Can include UTC (Z) or offset (+HH:MM)
• Range: Year 0000 to 9999 (extended format supports more)

Pros

• Human-readable and debugger-friendly
• Includes timezone information
• Sortable as strings (lexicographic order matches chronological)
• Widely supported in modern APIs (JSON, XML)
• Unambiguous format (no MM/DD vs DD/MM confusion)
• Native support in JavaScript via Date.toISOString()

Cons

• Larger storage footprint (19-29 bytes as string)
• Slower parsing compared to integers
• Multiple valid representations (with/without milliseconds, different timezone formats)
• String comparison slightly slower than numeric

When to Use

ISO 8601 is perfect for:

• JSON APIs (REST, GraphQL)
• Configuration files and human-editable data
• Logging where readability is important
• Situations where timezone context must be preserved
• CSV exports and data interchange

RFC 2822 (Email Date Format)

RFC 2822 defines the date format used in email headers and HTTP responses. It prioritizes human readability over machine parseability.

Characteristics

• Format: String (Day, DD Mon YYYY HH:MM:SS +ZZZZ)
• Precision: Seconds
• Timezone: Offset or abbreviation (GMT, EST, etc.)
• Range: Unlimited

Pros

• Very human-readable (includes day of week, month name)
• Standard for email and HTTP headers
• Includes timezone offset

Cons

• Not sortable as strings
• Locale-dependent (month and day names)
• Larger than other formats
• Parsing complexity varies by implementation
• Timezone abbreviations can be ambiguous (EST could be US or Australian Eastern)

When to Use

RFC 2822 is required for:

• Email headers (Date field)
• HTTP response headers (Last-Modified, Expires)
• RSS and Atom feeds
• Any system following email or HTTP standards

Millisecond Timestamps

A variant of Unix timestamps that counts milliseconds instead of seconds since the epoch. Popular in JavaScript and real-time systems.

Characteristics

• Format: Integer (64-bit)
• Precision: Milliseconds
• Timezone: Always UTC
• Range: ±285,616 years from epoch

Pros

• High precision for sub-second timing
• Native to JavaScript (Date.now() returns milliseconds)
• Useful for performance measurements and real-time systems
• Avoids Y2038 problem (uses 64-bit)

Cons

• Larger than second-precision timestamps (8 bytes vs 4 bytes)
• Can exceed JavaScript's safe integer range (2^53)
• Overkill if millisecond precision isn't needed

When to Use

Millisecond timestamps are ideal for:

• JavaScript applications and Node.js backends
• High-frequency trading systems
• Performance monitoring and profiling
• Real-time event ordering (chat, gaming)
• Systems requiring precise time synchronization

Microsecond and Nanosecond Timestamps

For systems requiring even higher precision, microseconds (10^-6 seconds) and nanoseconds (10^-9 seconds) are used.

When to Use

These high-precision formats are essential for:

• Distributed tracing (OpenTelemetry, Jaeger)
• Database transaction timestamps (PostgreSQL, Cassandra)
• Scientific computing and simulations
• Network packet timestamping
• High-frequency data acquisition

Excel/Lotus Serial Date Numbers

Microsoft Excel and Lotus 1-2-3 use a serial number system where dates are represented as the number of days since a base date.

Characteristics

• Format: Floating-point number
• Precision: Days (integer part), fractions of a day (decimal part)
• Base date: January 1, 1900 (Windows) or January 1, 1904 (Mac)
• Known issue: Incorrectly treats 1900 as a leap year

When to Use

Primarily when:

• Working with Excel spreadsheets
• Importing/exporting CSV data from Excel
• Integrating with legacy business systems that use Excel as a database

Format Comparison Table

Conversion Examples

Understanding how to convert between these formats is essential. Here are practical examples:

JavaScript/TypeScript

// Unix timestamp to ISO 8601
const unixSeconds = 1707350400;
const isoString = new Date(unixSeconds * 1000).toISOString();
console.log(isoString); // "2025-02-08T00:00:00.000Z"

// ISO 8601 to Unix timestamp
const isoDate = "2025-02-08T00:00:00Z";
const unixTimestamp = Math.floor(new Date(isoDate).getTime() / 1000);
console.log(unixTimestamp); // 1707350400

// Milliseconds to Unix seconds
const milliseconds = Date.now();
const seconds = Math.floor(milliseconds / 1000);

// Unix to RFC 2822
const date = new Date(1707350400 * 1000);
const rfc2822 = date.toUTCString();
console.log(rfc2822); // "Thu, 08 Feb 2025 00:00:00 GMT"

Python

from datetime import datetime, timezone

# Unix timestamp to ISO 8601
unix_seconds = 1707350400
iso_string = datetime.fromtimestamp(unix_seconds, tz=timezone.utc).isoformat()
print(iso_string)  # "2025-02-08T00:00:00+00:00"

# ISO 8601 to Unix timestamp
iso_date = "2025-02-08T00:00:00Z"
dt = datetime.fromisoformat(iso_date.replace('Z', '+00:00'))
unix_timestamp = int(dt.timestamp())
print(unix_timestamp)  # 1707350400

# Unix to RFC 2822
from email.utils import formatdate
rfc2822 = formatdate(timeval=1707350400, usegmt=True)
print(rfc2822)  # "Thu, 08 Feb 2025 00:00:00 GMT"

PHP

<?php
// Unix timestamp to ISO 8601
$unixSeconds = 1707350400;
$isoString = gmdate('Y-m-d\TH:i:s\Z', $unixSeconds);
echo $isoString; // "2025-02-08T00:00:00Z"

// ISO 8601 to Unix timestamp
$isoDate = "2025-02-08T00:00:00Z";
$unixTimestamp = strtotime($isoDate);
echo $unixTimestamp; // 1707350400

// Unix to RFC 2822
$rfc2822 = gmdate('D, d M Y H:i:s', 1707350400) . ' GMT';
echo $rfc2822; // "Thu, 08 Feb 2025 00:00:00 GMT"
?>

SQL

-- MySQL: Unix timestamp to datetime
SELECT FROM_UNIXTIME(1707350400);
-- Result: 2025-02-08 00:00:00

-- MySQL: Datetime to Unix timestamp
SELECT UNIX_TIMESTAMP('2025-02-08 00:00:00');
-- Result: 1707350400

-- PostgreSQL: Unix timestamp to timestamp
SELECT TO_TIMESTAMP(1707350400);
-- Result: 2025-02-08 00:00:00+00

-- PostgreSQL: Timestamp to Unix epoch
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2025-02-08 00:00:00 UTC');
-- Result: 1707350400

Best Practices

When choosing a timestamp format, consider these recommendations:

For Internal Storage

• Use Unix timestamps (64-bit) for efficiency and simplicity
• Store in UTC to avoid timezone complications
• Use millisecond timestamps if sub-second precision is required
• Index timestamp columns for query performance

For External APIs

• Prefer ISO 8601 for human readability and timezone clarity
• Always include timezone information (UTC recommended)
• Document your timestamp format in API specifications
• Consider providing both Unix and ISO 8601 in critical APIs
• Use a JSON Formatter to inspect API responses and verify timestamp fields are correctly formatted

For User Interfaces

• Display times in the user's local timezone
• Store Unix timestamps, convert to local time on display
• Use relative time for recent events ("2 hours ago")
• Provide timezone information when showing absolute times

For Interoperability

• Support multiple formats for input parsing (be liberal)
• Output a single, well-defined format (be conservative)
• Version your APIs when changing timestamp formats
• Test edge cases: leap seconds, DST transitions, Y2038

Common Pitfalls

Avoid these frequent mistakes when working with timestamps:

• Mixing seconds and milliseconds: JavaScript uses milliseconds, Unix uses seconds. Always convert explicitly.
• Ignoring timezones: "2025-02-08 12:00:00" without a timezone is ambiguous. Always specify UTC or an offset.
• Storing local time: Never store timestamps in local time unless absolutely necessary. Use UTC and convert on display.
• 32-bit timestamps for new projects: Always use 64-bit timestamps to avoid Y2038 issues.
• String comparison of non-ISO formats: Only ISO 8601 (YYYY-MM-DD...) sorts correctly as strings.

Tools and Resources

Need to convert between timestamp formats? Try our free Epoch Converter tool for instant conversion between Unix timestamps, ISO 8601, and human-readable dates, with support for multiple timezones.

Working with scheduled tasks that depend on precise timing? Our Cron Expression Builder helps you create and visualize cron schedules with natural language input and frequency analysis.