What 'current Unix timestamp' means
The current Unix timestamp is the count of seconds — or milliseconds, or microseconds, or nanoseconds — since 1970-01-01 00:00:00 UTC, evaluated at this moment. Every modern programming language ships a function that returns it. The number is timezone-neutral: two computers in different zones running the call at the same physical instant return the same value. Where languages differ is the unit (seconds vs milliseconds is the dominant split), the return type (integer, float, struct), and the underlying clock (wall-clock vs monotonic). Pick the right one for your use case and the rest is one line of code.
- Wall-clock 'now' (for storage, logs, API payloads): JavaScript Date.now(), Python time.time(), Go time.Now(), Java Instant.now()
- Monotonic 'now' (for benchmarks, timeouts): JavaScript performance.now(), Python time.monotonic(), Go time.Now() comparisons within a process
- Want to see the value right now? The live tool on the home page ticks every second
Current timestamp in seconds
Use seconds for most logs, server APIs, SQL filters, and Unix command-line workflows. The modern value is 10 digits.
Current timestamp in milliseconds
Use milliseconds for JavaScript Date, Java currentTimeMillis, .NET ToUnixTimeMilliseconds, and browser analytics events. The modern value is 13 digits.
Current timestamp is UTC-based
Timezone does not change the integer. UTC or local timezone only changes how the same instant is formatted for humans.
Get the current Unix timestamp in JavaScript
JavaScript's Date.now() returns the current Unix timestamp in milliseconds. It's a static method, so it skips constructing a Date object — a few percent faster than new Date().getTime() in hot loops, identical for occasional reads. For Unix seconds (the format most server APIs expect), divide by 1000 and floor. Date.now() reads the system wall-clock; if you need a clock that can't move backward (NTP step, manual adjustment), use performance.now() instead.
- Date.now() // 1750409100000 — current Unix milliseconds
- Math.floor(Date.now() / 1000) // 1750409100 — current Unix seconds
- new Date().getTime() // same as Date.now() but constructs a Date first
- +new Date() // unary-plus shortcut, same value
- performance.now() + performance.timeOrigin // sub-ms-precision Unix ms
- Node.js: Date.now() is identical to the browser; perf_hooks.performance.now() for monotonic
JavaScript now in seconds
Use Math.floor(Date.now() / 1000) when the receiving API documents Unix seconds.
JavaScript now in milliseconds
Use Date.now() directly when constructing Date objects or sending values to APIs that expect 13-digit milliseconds.
Get the current Unix timestamp in Python
Python's time.time() returns Unix seconds as a float — fractional sub-second precision is preserved. Cast to int when you want a 10-digit integer Unix timestamp. datetime.now(timezone.utc) returns a timezone-aware datetime; call .timestamp() to convert to Unix seconds. Always pass timezone.utc — without it, Python's local-timezone defaults produce different output on developer laptops and production hosts. For elapsed-time measurements, time.monotonic() returns a monotonic clock that never moves backward.
- import time
- time.time() # 1750409100.123 — fractional Unix seconds (float)
- int(time.time()) # 1750409100 — Unix seconds (int)
- int(time.time() * 1000) # 1750409100123 — Unix milliseconds (int)
- time.time_ns() # 1750409100123456789 — Unix nanoseconds (int), Python 3.7+
- from datetime import datetime, timezone
- datetime.now(timezone.utc).timestamp() # same as time.time()
- time.monotonic() # monotonic seconds since some arbitrary start — for benchmarks
Get the current Unix timestamp in Go
Go's time.Now() returns a time.Time struct in the local timezone; unwrap it with .Unix() for Unix seconds, .UnixMilli() for milliseconds, .UnixMicro() for microseconds, or .UnixNano() for nanoseconds. Go forces you to pick the unit, which eliminates the silent unit-drift bugs that bite codebases that mix Date.now() (ms) and time.time() (s) at boundaries. For elapsed time, compare two time.Now() values within the same process — Go's runtime uses a monotonic clock internally and exposes the difference via time.Since().
- time.Now().Unix() // 1750409100 — Unix seconds (int64)
- time.Now().UnixMilli() // 1750409100123 — Unix milliseconds (int64), Go 1.17+
- time.Now().UnixMicro() // microseconds, Go 1.17+
- time.Now().UnixNano() // nanoseconds (int64)
- time.Now().UTC() // forces UTC display; the timestamp itself is unchanged
- Elapsed: start := time.Now(); doWork(); elapsed := time.Since(start) // monotonic
Get the current Unix timestamp in Java and Kotlin
Java's java.time.Instant.now() is the canonical post-Java-8 API for getting the current instant. Instant.now().getEpochSecond() returns Unix seconds as a long; Instant.now().toEpochMilli() returns milliseconds. System.currentTimeMillis() is the legacy shortcut for milliseconds — still common in older code, identical result. Kotlin uses the same java.time API on JVM and Android API 26+; for older Android, use the ThreeTenABP backport or kotlinx-datetime's Clock.System.now().
- Instant.now() // current Instant (UTC, nanosecond precision)
- Instant.now().getEpochSecond() // long — Unix seconds
- Instant.now().toEpochMilli() // long — Unix milliseconds
- System.currentTimeMillis() // long — Unix milliseconds (legacy shortcut)
- System.nanoTime() // monotonic nanoseconds — for benchmarks only, NOT Unix time
- Kotlin (JVM): Instant.now().toEpochMilli() // same as Java
- Kotlin Multiplatform: Clock.System.now().toEpochMilliseconds()
Get the current Unix timestamp in C# / .NET
.NET 4.6+ ships DateTimeOffset.UtcNow.ToUnixTimeSeconds() and ToUnixTimeMilliseconds() as the dedicated converters. Both return a long anchored at UTC. DateTime.UtcNow.Ticks is the legacy form — it returns 100-nanosecond intervals since 0001-01-01, which is not a Unix timestamp; convert by subtracting the Unix epoch DateTime. .NET 6+ adds Stopwatch.GetTimestamp() for monotonic high-resolution timing.
- DateTimeOffset.UtcNow.ToUnixTimeSeconds() // long — Unix seconds
- DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() // long — Unix milliseconds
- DateTimeOffset.UtcNow.Ticks // 100-ns intervals since 0001-01-01 (NOT Unix time)
- Stopwatch.GetTimestamp() // monotonic high-res timer — for benchmarks
- Stopwatch.Frequency // ticks per second on this hardware
- .NET Framework < 4.6: (DateTime.UtcNow - new DateTime(1970,1,1,0,0,0,DateTimeKind.Utc)).TotalSeconds
Get the current Unix timestamp in PHP
PHP's time() returns the current Unix seconds as an integer — it's the shortest one-liner of any major language. For sub-second precision use microtime(true), which returns a float of Unix seconds with microsecond precision. The DateTime API gives you a richer object with the same underlying value. PHP works in seconds by default; multiply by 1000 if you need milliseconds for a JavaScript or Java consumer.
- time() // 1750409100 — Unix seconds (int)
- microtime(true) // 1750409100.123456 — Unix seconds with µs precision (float)
- (int)(microtime(true) * 1000) // 1750409100123 — Unix milliseconds
- (new DateTime())->getTimestamp() // 1750409100 — Unix seconds via DateTime
- (new DateTimeImmutable())->format('U') // '1750409100' — Unix seconds as string
- hrtime(true) // monotonic nanoseconds — PHP 7.3+; for benchmarks
Get the current Unix timestamp in Ruby, Swift, Rust, and C
The remaining widely-used languages each have a one-liner of their own. Ruby's Time.now.to_i is the simplest; Swift's Date().timeIntervalSince1970 returns a Double; Rust uses SystemTime::now() with a UNIX_EPOCH duration delta; C uses time(NULL) from <time.h> for seconds or clock_gettime() for higher precision. None of these surprise — they all return the same Unix-epoch-anchored value as the languages above, just with different type conventions.
- Ruby: Time.now.to_i // Integer — Unix seconds
- Ruby: (Time.now.to_f * 1000).to_i // Integer — Unix milliseconds
- Swift: Int(Date().timeIntervalSince1970) // Int — Unix seconds
- Swift: Int(Date().timeIntervalSince1970 * 1000) // Int — Unix milliseconds
- Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() // u64 seconds
- Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_millis() // u128 ms
- C: time(NULL) // time_t — Unix seconds
- C: struct timespec ts; clock_gettime(CLOCK_REALTIME, &ts); // ts.tv_sec + ts.tv_nsec
- C: clock_gettime(CLOCK_MONOTONIC, &ts); // monotonic for elapsed time
Get the current Unix timestamp in shell
Linux and BSD shells share the date command but accept different flags for the most useful variants. GNU date supports nanosecond precision via the %N format specifier; BSD date (macOS) doesn't. Windows PowerShell uses a .NET-based form. Every shell pattern below returns the same canonical Unix timestamp.
- Linux / macOS: date +%s // Unix seconds
- Linux: date +%s%3N // Unix milliseconds (GNU date only)
- Linux: date +%s%N // Unix nanoseconds (GNU date only)
- macOS: $(($(date +%s) * 1000 + $(date +%N | cut -c1-3))) // ms workaround
- PowerShell: [DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
- PowerShell: [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds()
- POSIX-portable: awk 'BEGIN { srand(); print srand() }' // returns Unix seconds
Linux current epoch seconds
date +%s is the portable answer for current epoch time on Linux and macOS.
Linux current epoch milliseconds
GNU date supports date +%s%3N. macOS BSD date does not expose %N, so use a runtime such as Python or Node when you need milliseconds.
Get the current Unix timestamp in SQL
Every major SQL database has a NOW()-like function that returns the current timestamp, plus an EXTRACT-style operator for converting to Unix seconds. The function names differ but the semantics are identical — they read the database server's clock at query time and return a TIMESTAMP value. For cross-region consistency, prefer TIMESTAMPTZ in PostgreSQL or always-UTC DATETIME conventions elsewhere.
- PostgreSQL: SELECT EXTRACT(EPOCH FROM NOW())::BIGINT // Unix seconds
- PostgreSQL: SELECT EXTRACT(EPOCH FROM clock_timestamp()) // truly current (NOW() is frozen per transaction)
- MySQL: SELECT UNIX_TIMESTAMP() // current Unix seconds
- MySQL: SELECT UNIX_TIMESTAMP(NOW(3)) * 1000 // current Unix milliseconds
- SQLite: SELECT strftime('%s', 'now') // current Unix seconds as text
- SQLite: SELECT (julianday('now') - 2440587.5) * 86400 // numeric alternative
- BigQuery: SELECT UNIX_SECONDS(CURRENT_TIMESTAMP())
- ClickHouse: SELECT toUnixTimestamp(now())
PostgreSQL current epoch time
EXTRACT(EPOCH FROM NOW()) returns seconds for the transaction timestamp. Use clock_timestamp() when you need the actual wall clock during a long query.
MySQL and SQLite current timestamp
MySQL's UNIX_TIMESTAMP() and SQLite's strftime('%s', 'now') both return current Unix seconds.
Clock drift, NTP, and why 'current' isn't always identical between hosts
Two hosts running 'get the current timestamp' at the same physical instant return slightly different numbers in the real world. The difference comes from clock drift: hardware oscillators run at slightly different rates, virtualized clocks fall behind under load, and operating systems correct via NTP (Network Time Protocol) — the RFC 5905 standard that synchronizes clocks against authoritative time sources. Well-configured production hosts sync to within 1-5 ms of true UTC; without NTP, drift can reach several seconds per day. For high-precision distributed systems, use a monotonic clock for elapsed-time measurements rather than relying on wall-clock synchronization across hosts.
- Typical NTP-synced precision: ±1-5 ms from true UTC on a healthy server
- Unsynced drift: 1-10 seconds per day on commodity hardware
- Containerized workloads: depend on the host clock; clock_gettime() in a container reads the host's value
- Distributed systems: use monotonic time for elapsed-time math, wall-clock only for storage and logs
- For high-precision: PTP (Precision Time Protocol, IEEE 1588) achieves microsecond sync over LAN
- Recent news on the site: Ubuntu 26.04 moves new installs to Chrony for authenticated NTP
Quick reference — current timestamp in every language
The same call across every common runtime, side by side. Use this as a paste-friendly reference when porting code or reviewing a PR that touches 'current time' at a system boundary. Every line returns the current Unix timestamp anchored to 1970-01-01 UTC; the only differences are the unit and return type.
- JavaScript: Date.now() // ms
- Python: int(time.time()) // s
- Go: time.Now().Unix() // s
- Java: Instant.now().getEpochSecond() // s
- Kotlin: Instant.now().toEpochMilli() // ms
- C#: DateTimeOffset.UtcNow.ToUnixTimeSeconds() // s
- PHP: time() // s
- Ruby: Time.now.to_i // s
- Swift: Int(Date().timeIntervalSince1970) // s
- Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() // s
- C: time(NULL) // s
- Linux shell: date +%s // s
- PowerShell: [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() // s
- Postgres SQL: SELECT EXTRACT(EPOCH FROM NOW())::BIGINT // s
- MySQL SQL: SELECT UNIX_TIMESTAMP() // s
FAQ
- What is epoch time now?
- Epoch time now is the current Unix timestamp: the number of seconds since 1970-01-01 00:00:00 UTC at this instant. The homepage shows the live value; code usually reads it with date +%s, Math.floor(Date.now() / 1000), or int(time.time()).
- What's the simplest way to get the current Unix timestamp?
- Depends on the language. JavaScript: Date.now(). Python: int(time.time()). Go: time.Now().Unix(). Java: Instant.now().getEpochSecond(). Linux shell: date +%s. Every modern language ships a one-liner — the choice between seconds and milliseconds and the timezone (always UTC) are the same across all of them.
- Does the current Unix timestamp depend on my timezone?
- No. A Unix timestamp is a timezone-neutral integer — the count of seconds since 1970-01-01 UTC. Two computers in different timezones running 'get current timestamp' at the same instant return the same number. Timezone only matters when you format the number for display.
- Why is my current timestamp 13 digits and not 10?
- Because your runtime returns milliseconds rather than seconds. JavaScript Date.now(), Java System.currentTimeMillis(), and .NET DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() all return milliseconds. Divide by 1000 (and floor) to get 10-digit Unix seconds.
- Is the current Unix timestamp the same on every server?
- Within milliseconds, yes — if NTP is running. Most production hosts sync to within 1-5 ms of true UTC via NTP or PTP. Without time sync, drift can reach several seconds per day. For high-precision distributed systems, use a monotonic clock for elapsed-time measurements rather than relying on wall-clock synchronization.
- How accurate is Date.now() / time.time() / Instant.now()?
- Wall-clock precision is whatever the OS reports — usually millisecond or sub-millisecond. Wall-clock accuracy depends on the host's NTP sync quality. For benchmarks and rate-limiting use a monotonic clock instead (performance.now() in JS, time.monotonic() in Python, time.monotonic_ns() in Python 3.7+).
- What's the difference between wall-clock and monotonic time?
- Wall-clock time is the system's belief about UTC — it can jump forward or backward when NTP adjusts the clock. Monotonic time is a counter that only moves forward, with no relationship to UTC. Use wall-clock for 'when did this happen' (timestamps, logs). Use monotonic for 'how long did it take' (benchmarks, timeouts, rate limiters).
- How do I get the current timestamp in milliseconds in every language?
- JavaScript: Date.now(). Java: System.currentTimeMillis(). C#: DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(). Python: int(time.time() * 1000). Go: time.Now().UnixMilli(). Rust (chrono): Utc::now().timestamp_millis(). Linux: date +%s%3N.
- How do I get current epoch time in SQL?
- PostgreSQL: SELECT EXTRACT(EPOCH FROM NOW())::BIGINT. MySQL: SELECT UNIX_TIMESTAMP(). SQLite: SELECT strftime('%s', 'now'). BigQuery: SELECT UNIX_SECONDS(CURRENT_TIMESTAMP()).
- Why does the current timestamp differ between my computer and a server?
- Usually because one of them has drifted from UTC. NTP keeps most hosts within 5 ms; without it, drift can be seconds per day. Other causes: incorrect timezone setting (rare — Unix time is tz-neutral, but the OS clock might be set wrong), virtualization clock skew, and rare hardware clock failures.
- Should I store the current timestamp as seconds or milliseconds?
- Match the source system. If a JavaScript client writes the value, milliseconds is the safer default. If a server-side Python or Go pipeline writes it, seconds is the convention. Always name the field with the unit (createdAtMs, expiresAtSeconds) so future readers don't have to guess.