Unix Epoch Time: The Global Standard for Developers

Category: Dev Tools

TL;DR: Unix epoch time is the number of seconds (or milliseconds) since 1970-01-01 00:00:00 UTC. It’s fast for comparisons, compact to store, timezone-agnostic, and universally supported across languages and databases. Use UTC internally, ISO 8601/RFC 3339 at your API boundaries, and 64-bit timestamp types to dodge the Year 2038 bug. Instantly convert timestamps with the privacy-first Zenixtools Epoch Converter.

—

Key takeaways (quick answers)

• Unix epoch time = seconds since 1970-01-01 00:00:00 UTC (no time zone offset baked in).
• Digits matter:
  • 10 digits = seconds (e.g., 1716940800)
  • 13 digits = milliseconds (e.g., 1716940800000)
  • 16 digits = microseconds (e.g., 1716940800000000)
  • 19 digits = nanoseconds (e.g., 1716940800000000000)
• Fast comparisons, sorting, math; compact storage.
• Y2038 affects some 32-bit systems using signed 32-bit seconds; 64-bit is safe.
• Conversions: use the Zenixtools Epoch Converter (client-side, no tracking): https://www.zenixtools.com/tools/epoch-converter

What is Unix epoch time?

Unix epoch time (often called "Unix time" or "POSIX time") is a single integer that counts how many seconds have elapsed since the Unix epoch: 1970-01-01 00:00:00 UTC. It’s the lowest common denominator for time across operating systems, databases, programming languages, and APIs.

Why it exists:

• Different regions write the same date differently (MM/DD vs DD/MM).
• Time zones and daylight saving time introduce offsets and jumps.
• Human-friendly strings are slow to parse and easy to misinterpret.

Epoch time solves this by representing a moment as a monotonic counter in UTC. You only apply a time zone when you display the timestamp to a human.

Authoritative references:

• POSIX time (The Open Group): https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
• IANA Time Zone Database: https://www.iana.org/time-zones
• RFC 3339 (ISO-like internet timestamp format): https://www.rfc-editor.org/rfc/rfc3339

A note on leap seconds

POSIX/Unix time does not count leap seconds. In practice, most systems treat UTC as a continuous count of SI seconds minus leap seconds (or apply a smear, like Google’s leap smear). This means:

• A minute may have a leap second in official UTC, but epoch time ignores it or smears it.
• For most app use cases (logging, ordering, caches, scheduling), this is fine.
• For scientific or financial systems needing sub-second precision across leap seconds, consider TAI or specialized libraries and document your approach.

Seconds vs milliseconds (and beyond)

Epoch values appear in several common units. Recognize them at a glance:

• 10-digit numbers: seconds since the epoch
  • Example: 1716940800
  • Common sources: PostgreSQL EXTRACT(EPOCH), Linux date +%s, Go time.Unix()
• 13-digit numbers: milliseconds since the epoch
  • Example: 1716940800000
  • Common sources: JavaScript Date.now(), Java Instant.toEpochMilli()
• 16-digit numbers: microseconds since the epoch
  • Example: 1716940800000000
  • Common sources: Some SQL databases, Python time in microseconds (when multiplied)
• 19-digit numbers: nanoseconds since the epoch
  • Example: 1716940800000000000
  • Common sources: High-precision tracing, Rust/Go nanos, some logs

Practical checks:

• If a value is > 10^11, it’s probably not seconds (likely ms or more).
• To normalize:
  • If milliseconds, divide by 1000 for seconds.
  • If microseconds, divide by 1,000,000 for seconds.
  • If nanoseconds, divide by 1,000,000,000 for seconds.

Pro tip: Always label fields with their unit (created_at_ms, updated_at_ns) to avoid confusion.

Why developers choose epoch time

• Simple comparisons: newer > older in constant time.
• Easy math: add/subtract durations without calendar quirks.
• Compact storage: one integer field; efficient indexes.
• Cross-language consistency: no locale or tz parsing required.
• Stream-friendly: binary-friendly for logs, analytics, and message queues.

Where epoch shines:

• Logs, metrics, and traces
• Caches and TTLs
• Idempotency and deduplication (e.g., sorting events)
• Analytics pipelines and partitioning

Where to be careful:

• Human scheduling, recurring events, and calendaring (DST and rules change). Use domain libraries (e.g., IANA tz, rrule) and store base rules separately.

How epoch differs from ISO 8601/RFC 3339

• Epoch: machine-friendly integer, always UTC. Best for storage and compute.
• ISO 8601/RFC 3339: human-friendly string with timezone info (e.g., 2026-01-15T12:34:56Z or 2026-01-15T07:34:56-05:00). Best for APIs, logs for people, and UI.

Recommended pattern:

• Store in UTC epoch internally.
• Expose RFC 3339 at public boundaries (APIs, CSV exports, logs viewed by humans).

Quick conversion reference

• Seconds → ISO 8601 UTC: format epoch_seconds into RFC 3339 with Z.
• Milliseconds → ISO 8601 UTC: new Date(ms).toISOString() in JS (or language equivalent).
• RFC 3339 → Epoch: parse the string as UTC and convert to seconds/millis.

Common pitfalls:

• Confusing local time for UTC when converting.
• Off-by-1000 errors when mixing seconds and milliseconds.
• DST illusions (times appear to "repeat" locally). Store UTC.

Try it now: Zenixtools Epoch Converter (client-side, private)

Convert timestamps in seconds or milliseconds instantly. No server round-trips; your data stays in your browser.

• Paste a 10-, 13-, 16-, or 19-digit timestamp to see UTC and local time
• Pick a date/time to generate the epoch value
• Toggle seconds/milliseconds, copy results quickly

Links:

• Zenixtools Epoch Converter: https://www.zenixtools.com/tools/epoch-converter
• Learn more: https://www.zenixtools.com
• Privacy policy: https://www.zenixtools.com/privacy

Code examples (Epoch ↔ Date)

JavaScript (Node & Browser)

// Now → epoch
const seconds = Math.floor(Date.now() / 1000);
const millis  = Date.now();

// Epoch (seconds) → Date
const dSec = new Date(1716940800 * 1000);

// Epoch (milliseconds) → Date
const dMs = new Date(1716940800000);

// Date → ISO 8601 (UTC)
console.log(dMs.toISOString());

Single-liners:

• Seconds now: Math.floor(Date.now() / 1000)
• ISO for an epoch seconds value s: new Date(s * 1000).toISOString()

Python 3

import datetime as dt

# Now → epoch
seconds = int(dt.datetime.now(dt.timezone.utc).timestamp())
millis  = int(dt.datetime.now(dt.timezone.utc).timestamp() * 1000)

# Epoch (seconds) → datetime (UTC)
dt_utc = dt.datetime.fromtimestamp(1716940800, tz=dt.timezone.utc)

# To local timezone
dt_local = dt_utc.astimezone()

# RFC 3339
iso = dt_utc.isoformat().replace('+00:00', 'Z')

Java (java.time)

import java.time.*;

// Now → epoch
long seconds = Instant.now().getEpochSecond();
long millis  = Instant.now().toEpochMilli();

// Epoch (seconds) → ZonedDateTime
ZonedDateTime zdt = Instant.ofEpochSecond(1716940800).atZone(ZoneId.of("UTC"));
String iso = zdt.toInstant().toString(); // RFC 3339 with Z

Go

package main
import (
  "fmt"
  "time"
)
func main() {
  now := time.Now().UTC()
  seconds := now.Unix()
  millis  := now.UnixMilli()

  t := time.Unix(1716940800, 0).UTC()
  fmt.Println(t.Format(time.RFC3339))
}

C# (.NET)

using System;

// Now → epoch
long seconds = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
long millis  = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();

// Epoch (seconds) → DateTimeOffset (UTC)
var dto = DateTimeOffset.FromUnixTimeSeconds(1716940800);
string iso = dto.ToUniversalTime().ToString("o"); // ISO 8601

PHP

<?php
// Now → epoch
$seconds = time();
$millis = (int) round(microtime(true) * 1000);

// Epoch (seconds) → DateTime (UTC)
$dt = (new DateTime('@1716940800'))->setTimezone(new DateTimeZone('UTC'));
$iso = $dt->format(DateTime::ATOM); // RFC 3339

Ruby

# Now → epoch
seconds = Time.now.to_i
millis  = (Time.now.to_f * 1000).to_i

# Epoch (seconds) → Time (UTC)
utc = Time.at(1716940800).utc
iso = utc.iso8601

Rust

use chrono::{DateTime, TimeZone, Utc};

fn main() {
    // Epoch (seconds) → DateTime<Utc>
    let dt: DateTime<Utc> = Utc.timestamp_opt(1716940800, 0).unwrap();
    println!("{}", dt.to_rfc3339());
}

Swift

import Foundation

// Now → epoch
let seconds = Int(Date().timeIntervalSince1970)
let millis  = Int(Date().timeIntervalSince1970 * 1000)

// Epoch (seconds) → Date
let date = Date(timeIntervalSince1970: 1716940800)
let iso = ISO8601DateFormatter().string(from: date)

Bash (GNU date)

# Now → epoch (seconds)
date +%s

# Epoch (seconds) → local time
date -d @1716940800

# Epoch (seconds) → RFC 3339 UTC
date -u -d @1716940800 +"%Y-%m-%dT%H:%M:%SZ"

Note: On macOS (BSD date), use:

# macOS: epoch → local time
date -r 1716940800
# macOS: epoch → RFC 3339 UTC
TZ=UTC date -r 1716940800 +"%Y-%m-%dT%H:%M:%SZ"

SQL snippets

• PostgreSQL

-- Now → epoch seconds
SELECT EXTRACT(EPOCH FROM NOW());

-- Epoch seconds → timestamp with time zone (UTC)
SELECT to_timestamp(1716940800) AT TIME ZONE 'UTC';

-- ISO 8601 string → epoch seconds
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2026-06-01T12:34:56Z');

• MySQL / MariaDB

-- Now → epoch seconds
SELECT UNIX_TIMESTAMP();

-- Epoch seconds → datetime (UTC depends on session time_zone)
SELECT FROM_UNIXTIME(1716940800);

• BigQuery

-- Epoch milliseconds → TIMESTAMP
SELECT TIMESTAMP_MILLIS(1716940800000);

The Year 2038 problem (Y2038)

Legacy 32-bit systems often store epoch time as a signed 32-bit integer in seconds. The largest value is 2,147,483,647, which corresponds to 2038-01-19 03:14:07 UTC. One second later, it overflows to negative and appears as dates in 1901.

Who might still be affected:

• Older 32-bit OSes and kernels
• Embedded/IoT firmware
• Outdated C libraries, drivers, or language runtimes compiled for 32-bit
• Old database drivers or custom binary formats with 32-bit time fields

How to mitigate now:

• Audit: Search your code and schemas for 32-bit time_t or INT32 timestamp fields.
• Migrate: Use 64-bit time representations (time64_t, long long, BIGINT) and ensure your OS, libc, and runtimes are Y2038-safe.
• Databases: Use BIGINT for epoch; test ORM mappings; add migration scripts.
• Compatibility: Version data formats and provide backfills/reindexing.

Good news: Modern 64-bit platforms and mainstream libraries are already Y2038-safe when using 64-bit time types.

Related long-range limits (for perspective):

• 64-bit seconds: ±292,278,994,000 years from 1970
• 64-bit milliseconds: ±292,278,994 years
• 64-bit nanoseconds: ±292 years (that’s why some systems cap at year 2262)

More reading:

• Linux time(7): https://man7.org/linux/man-pages/man7/time.7.html
• glibc Y2038 notes: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Best practices (battle-tested)

• Store UTC everywhere. Convert to local time only for display.
• Name fields with units: created_at_s, created_at_ms, expires_at_ns.
• Use 64-bit integers for timestamps (BIGINT, long long, i64).
• Prefer RFC 3339 for APIs and logs humans will read (include Z or offset).
• Validate input length and range before arithmetic (avoid accidental ms→s truncation).
• Avoid timezone-naïve datetime types in DBs. Use timestamptz or epoch BIGINT.
• For recurring events, store the rule (e.g., "every Mon 9am America/New_York") and compute occurrences with tzdata, not by naive epoch arithmetic.
• Handle DST boundaries in scheduling: runbooks should include tz change tests.
• For observability, keep timestamps consistent across services and logs.

Common pitfalls and how to fix them

• Off-by-1000: Treated milliseconds as seconds (or vice versa).
  • Fix: Assert expected range and digits; add unit-specific types or wrappers.
• Local vs UTC confusion in clients, especially mobile and JavaScript.
  • Fix: Convert on display; set explicit tz in formatters; use Z.
• DST repeat/skipped hours cause duplicate/missing job triggers.
  • Fix: Schedule in UTC; or use timezone-aware scheduler libs with rules.
• Inconsistent DB column types across services.
  • Fix: Centralize schema contracts; prefer BIGINT epoch or timestamptz.
• Parsing text timestamps in hot paths.
  • Fix: Use epoch internally; only render strings at edges.

Performance and storage tips

• Indexing: BIGINT epoch fields index and sort efficiently.
• Partitioning: Partition large tables by day/week/month using epoch ranges.
• TTL and compaction: Use epoch-based expiration for logs/metrics to simplify cleanup.
• Compression: Epoch integers compress well (delta or run-length encodings).

Testing and reliability

• Table-driven tests around DST changes (e.g., March/November in US) and tz shifts.
• Property-based tests for add/subtract duration invariants.
• Fuzz input lengths and non-digit characters in parsers.
• Snapshot tests for APIs: roundtrip RFC 3339 ↔ epoch.

Quick cheatsheet (copy-paste)

• Is this seconds or milliseconds?

  • 10 digits ≈ seconds
  • 13 digits ≈ milliseconds
  • Rule of thumb: > 10^11 → not seconds

• Convert milliseconds to seconds: Math.floor(ms / 1000)

• Convert seconds to milliseconds: s * 1000

• RFC 3339 UTC suffix: "Z" (e.g., 2026-06-01T12:34:56Z)

• Safe integer type: 64-bit signed (BIGINT, int64, long long)

Real-world examples you’ll see

• JavaScript frontends: Date.now() → 13-digit ms
• Backend logs: seconds or ms depending on logger config
• Databases:
  • PostgreSQL: EXTRACT(EPOCH) → seconds (double); use BIGINT to store whole seconds
  • MySQL: UNIX_TIMESTAMP() → seconds
  • BigQuery: TIMESTAMP_MILLIS for ms input
• Observability: Traces often include high-precision ns; normalize before storage

Security, privacy, and compliance

• Minimize PII: Timestamps are metadata—still handle carefully in logs.
• Clock integrity: Use NTP or chrony to avoid drift. Drift breaks ordering and SLAs.
• Tamper evidence: Sign or checksum critical event timestamps in audit trails.
• Regulatory exports: Provide RFC 3339 with time zone info for audits; keep source epoch values for integrity.

Frequently asked questions (FAQ)

Q: What is Unix epoch time in one sentence? A: The number of seconds since 1970-01-01 00:00:00 UTC.

Q: Does epoch time include time zones? A: No. It’s defined in UTC. Apply time zones when formatting for humans.

Q: 10 vs 13 digits—what’s the difference? A: 10 = seconds, 13 = milliseconds. Larger counts (16, 19) are micro-/nanoseconds.

Q: Is the Year 2038 bug still a problem? A: Only for 32-bit systems or code that stores seconds in signed 32-bit integers. Use 64-bit.

Q: Should I store seconds or milliseconds? A: Store the smallest unit your use case needs. Seconds are fine for many apps; milliseconds for UI/analytics; micro/nano for tracing. Label fields with units.

Q: Why do leap seconds not show up in epoch time? A: POSIX time ignores leap seconds (or smears them). This keeps arithmetic simple for most systems.

Q: What format should my API return? A: RFC 3339 (ISO 8601-like) with timezone info (Z or offset). Optionally include the raw epoch for clients.

Q: How do I detect if a timestamp is ms or s? A: Check magnitude/digits. > 10^11 is likely ms+. Or require explicit units in your APIs.

Q: Can I sort timestamps as strings? A: Yes for zero-padded epoch integers or RFC 3339 UTC with the same precision; otherwise, sort by numeric epoch.

Q: Does JavaScript lose precision for large timestamps? A: JS numbers are doubles. Use BigInt for ns or very large integers, or libraries that support high precision.

Glossary

• Epoch (Unix): 1970-01-01 00:00:00 UTC, the zero point for counting.
• POSIX time: Seconds since epoch, ignoring leap seconds.
• RFC 3339: An Internet standard timestamp format (subset of ISO 8601).
• IANA tz database: Canonical time zone rules (e.g., America/New_York).
• Y2038: 32-bit signed integer overflow for seconds since epoch.

Implementation checklist

• Decide your unit (s/ms/us/ns) and document it clearly.
• Store UTC internally; convert only for display.
• Use 64-bit integer types for epoch values everywhere.
• Emit RFC 3339 at API boundaries; include explicit offset or Z.
• Validate and normalize inbound timestamps.
• Write DST/tz boundary tests for scheduled jobs.
• Monitor time sync (NTP/chrony) and alert on drift.

Convert timestamps now (free tool)

Use the Zenixtools Epoch Converter to translate between epoch and human-readable timestamps without leaving your browser.

• https://www.zenixtools.com/tools/epoch-converter

Structured data (copy–paste JSON-LD)

[
  {
    "@context": "https://schema.org",
    "@type": "WebPage",
    "name": "Unix Epoch Time: The Global Standard for Developers",
    "url": "https://www.zenixtools.com/tools/epoch-converter",
    "description": "Understand Unix epoch time, convert timestamps instantly, and prepare for Y2038 with examples, best practices, and multi-language snippets.",
    "about": [
      { "@type": "Thing", "name": "Unix time" },
      { "@type": "Thing", "name": "Epoch converter" },
      { "@type": "Thing", "name": "Year 2038 problem" }
    ],
    "publisher": {
      "@type": "Organization",
      "name": "Zenixtools",
      "url": "https://www.zenixtools.com"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "SoftwareApplication",
    "name": "Zenixtools Epoch Converter",
    "applicationCategory": "DeveloperApplication",
    "operatingSystem": "Any",
    "url": "https://www.zenixtools.com/tools/epoch-converter",
    "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" },
    "privacyPolicy": "https://www.zenixtools.com/privacy",
    "description": "A fast, client-side Unix epoch converter for seconds and milliseconds that preserves user privacy."
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "What is Unix epoch time?",
        "acceptedAnswer": {"@type": "Answer", "text": "It is the number of seconds elapsed since 1970-01-01 00:00:00 UTC."}
      },
      {
        "@type": "Question",
        "name": "What is the difference between 10 and 13 digit timestamps?",
        "acceptedAnswer": {"@type": "Answer", "text": "10 digits represent seconds. 13 digits represent milliseconds."}
      },
      {
        "@type": "Question",
        "name": "Does epoch time include time zones?",
        "acceptedAnswer": {"@type": "Answer", "text": "No. Epoch time is defined in UTC. Time zones are applied only when formatting for display."}
      },
      {
        "@type": "Question",
        "name": "What is the Year 2038 problem?",
        "acceptedAnswer": {"@type": "Answer", "text": "Some 32-bit systems will overflow their time representation in 2038, causing incorrect dates. 64-bit systems avoid this."}
      },
      {
        "@type": "Question",
        "name": "Should I store seconds or milliseconds?",
        "acceptedAnswer": {"@type": "Answer", "text": "Use the smallest unit that meets your precision needs. Always label fields with the unit (e.g., created_at_ms)."}
      }
    ]
  }
]

About the author

This guide was prepared by the Zenixtools content team with contributions from senior engineers who build developer-facing utilities used by thousands of developers monthly. We actively maintain our tools and documentation to reflect current platform behaviors, time standards, and production best practices.

—

Conclusion: Unix epoch time remains the universal, high-performance foundation for representing moments in software. Use UTC internally, label your units, choose 64-bit, and convert for humans at the edge. When in doubt—or when debugging logs at 2 a.m.—drop your value into the Zenixtools Epoch Converter and get instant clarity.

Start converting: https://www.zenixtools.com/tools/epoch-converter