🌐 Language: πŸ‡ΊπŸ‡Έ English Β· πŸ‡§πŸ‡· PortuguΓͺs

Timestamp Now β€” Unix Epoch Converter 2026

Get the current Unix timestamp in seconds and milliseconds. Convert epoch to date/time and back. Supports ISO 8601 and timezones.

Current Timestamp
β€”
seconds Β· UTC+0
Timestamp β†’ Date
Date β†’ Timestamp

⏱️ What is a Unix Timestamp?

A Unix timestamp (also called Unix time, POSIX time, or epoch time) is a universal way to represent any point in time as a single integer: the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC β€” known as the Unix Epoch.

It is the most widely used standard in software development for storing, comparing and transmitting dates and times, because it eliminates ambiguities from timezones, local date formats and different calendar systems. A timestamp is just a number β€” simple, precise, and universally understood by any programming language or operating system.

πŸ“Œ

Quick example: Timestamp 1700000000 equals November 14, 2023 at 22:13:20 UTC. In milliseconds, the same instant is 1700000000000 β€” just multiply by 1,000.

πŸ•°οΈ The History of Unix Time

Unix was developed between 1969 and 1971 at Bell Labs by Ken Thompson, Dennis Ritchie and others. They needed a simple way to represent time in the operating system. January 1, 1970 was chosen because it was recent enough to avoid negative numbers for current dates, yet provided enough historical range. With 32-bit integers, the system could represent dates from 1901 to 2038. The standard was adopted by POSIX in 1988 and is now supported by every modern programming language and operating system in existence.

⚠️

The Year 2038 Problem (Y2K38): Systems using signed 32-bit integers to store timestamps will overflow on January 19, 2038 at 03:14:07 UTC β€” when the counter reaches its maximum of 2,147,483,647. The fix is to use 64-bit integers (supports dates until year 292,277,026,596). Most modern systems already do this, but legacy and embedded systems may still be at risk.

πŸ“Š Seconds vs Milliseconds vs Microseconds

UnitExample (~2026)DigitsUsed in
Seconds (s)174500000010Unix standard, databases, server logs
Milliseconds (ms)174500000000013JavaScript Date.now(), REST APIs, UI events
Microseconds (ΞΌs)174500000000000016Performance profiling, high-frequency databases
Nanoseconds (ns)174500000000000000019Real-time systems, HFT networks
πŸ’‘

How to identify the unit by digit count: In 2026, a timestamp in seconds has 10 digits (~1.74 billion). In milliseconds it has 13 digits. Counting digits is the fastest way to identify which unit you're dealing with.

πŸ’» Timestamp in Different Languages

JavaScript
// Current timestamp in milliseconds
const ms = Date.now();                     // 1745000000000

// In seconds
const s = Math.floor(Date.now() / 1000);  // 1745000000

// Timestamp β†’ Date (remember to multiply by 1000!)
const d = new Date(1700000000 * 1000);
console.log(d.toISOString());             // "2023-11-14T22:13:20.000Z"
console.log(d.toLocaleString('en-US'));   // "11/14/2023, 10:13:20 PM"

// Date β†’ Timestamp (seconds)
const ts = Math.floor(new Date('2024-01-01').getTime() / 1000);

// Difference between two dates in days
const diffDays = (Date.now() - 1700000000000) / 1000 / 86400;
Python
import time
from datetime import datetime, timezone

# Current timestamp
ts = int(time.time())           # seconds: 1745000000
ms = int(time.time() * 1000)   # milliseconds: 1745000000000

# Timestamp β†’ datetime (always use UTC!)
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(dt.isoformat())           # 2023-11-14T22:13:20+00:00

# datetime β†’ timestamp
dt2 = datetime(2024, 1, 1, tzinfo=timezone.utc)
ts2 = int(dt2.timestamp())      # 1704067200

# Difference between dates
diff_days = (time.time() - 1700000000) / 86400
SQL
-- MySQL / MariaDB
SELECT UNIX_TIMESTAMP();                         -- current timestamp
SELECT FROM_UNIXTIME(1700000000);                -- '2023-11-14 22:13:20'
SELECT UNIX_TIMESTAMP('2024-01-01 00:00:00');    -- 1704067200

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;        -- current timestamp
SELECT TO_TIMESTAMP(1700000000);                 -- '2023-11-14 22:13:20+00'
SELECT TO_TIMESTAMP(1700000000) AT TIME ZONE 'America/New_York';

-- SQLite
SELECT strftime('%s', 'now');                    -- current timestamp
SELECT datetime(1700000000, 'unixepoch');        -- '2023-11-14 22:13:20'
Bash / CLI
# Current timestamp
date +%s                           # seconds
date +%s%3N                        # milliseconds

# Timestamp β†’ readable date
date -d @1700000000                # Linux (GNU date)
date -r 1700000000                 # macOS / BSD

# Date β†’ timestamp
date -d "2024-01-01 00:00:00" +%s  # Linux
date -j -f "%Y-%m-%d" "2024-01-01" +%s  # macOS

🌍 Timezones and UTC

Unix timestamps are always in UTC (Coordinated Universal Time) β€” there is no timezone embedded in the number itself. Converting to local time is the application's responsibility. This is the most common source of timezone-related bugs in software.

TimezoneUTC OffsetTimestamp 1700000000 =
UTC / GMT+00:00Nov 14, 2023 22:13:20
New York (ET)βˆ’05:00 / βˆ’04:00Nov 14, 2023 17:13:20
Los Angeles (PT)βˆ’08:00 / βˆ’07:00Nov 14, 2023 14:13:20
London (GMT/BST)+00:00 / +01:00Nov 14, 2023 22:13:20
Berlin (CET/CEST)+01:00 / +02:00Nov 14, 2023 23:13:20
SΓ£o Paulo (BRT)βˆ’03:00Nov 14, 2023 19:13:20
Tokyo (JST)+09:00Nov 15, 2023 07:13:20
⚠️

Always use timezone names, not fixed offsets. Use America/New_York instead of -05:00, because DST (Daylight Saving Time) changes the offset twice a year. Fixed offsets will silently produce wrong results during DST transitions.

❓ Frequently Asked Questions

JavaScript was created in 1995 for browsers, where millisecond precision is essential for animations, mouse/keyboard events, and UI timers. Unix was designed for operating systems, where second-level precision is sufficient for most tasks. In practice: Date.now() returns milliseconds, so always divide by 1000 to compare with Unix timestamps in seconds. Forgetting this conversion is one of the most common bugs when integrating with backend APIs.

It depends on the use case:

  • BIGINT (Unix ms): less storage, easy to compare, timezone-independent. Best for event logs, distributed systems, and high-frequency writes.
  • TIMESTAMPTZ (PostgreSQL): stores UTC with full timezone support, native date functions, readable in queries. Best for most application-level date handling.
  • DATETIME (MySQL): beware β€” MySQL's TIMESTAMP type auto-converts to local time on storage, which can cause subtle bugs in distributed systems.

Recommendation: use BIGINT in milliseconds for backend event systems, TIMESTAMPTZ for PostgreSQL application data.

Date arithmetic with timestamps is just subtraction β€” the biggest advantage of the format:

  • Seconds: ts2 - ts1
  • Minutes: (ts2 - ts1) / 60
  • Hours: (ts2 - ts1) / 3600
  • Days: (ts2 - ts1) / 86400

Useful constants: 1 min = 60s | 1 hour = 3,600s | 1 day = 86,400s | 1 week = 604,800s | 1 year β‰ˆ 31,536,000s (365 days).

ISO 8601 is the international standard for representing dates and times as text: 2024-01-15T14:30:00Z. The Z suffix means UTC; -05:00 means Eastern Time.

  • Use ISO 8601 for public APIs, JSON responses, config files, and logs that need to be human-readable.
  • Use Unix timestamp for database storage, mathematical comparisons, high-performance systems, and internal inter-service communication.

Most modern REST APIs accept and return ISO 8601. Timestamps are more common in database internals and Unix/Linux system programming.

Negative timestamps represent dates before January 1, 1970. For example, -86400 is December 31, 1969 at 00:00:00 UTC. Most languages support negative timestamps for historical dates β€” JavaScript accepts any integer in new Date(), Python's datetime.fromtimestamp() supports them on most platforms. For very old historical dates (pre-1970), consider using specialized date libraries like date-fns, Luxon (JS) or Arrow (Python) for better handling of edge cases.

πŸ“Œ Quick Reference

⏱️

Current timestamp (2026): ~1,745,000,000 seconds | ~1,745,000,000,000 ms. Count the digits: 10 = seconds, 13 = milliseconds.

🌍

Always UTC. Timestamps have no timezone β€” conversion to local time is the app's job. Use timezone names (America/New_York), never fixed offsets.

⚠️

Y2038: 32-bit systems overflow on Jan 19, 2038. Use 64-bit integers (BIGINT) in all new systems.

πŸ”’

Useful constants: 1 min = 60s | 1 hour = 3,600s | 1 day = 86,400s | 1 week = 604,800s | 1 year β‰ˆ 31,536,000s.

πŸ› οΈ More free developer tools

⚠️ Some tools have their interface in Portuguese (Brazil) β€” but they work perfectly for any developer worldwide.