Unix Time Code Examples
Copy-ready snippets for getting the current Unix timestamp and converting epoch values in 10 languages. All snippets use UTC to avoid time zone bugs.
const nowSeconds = Math.floor(Date.now() / 1000);const nowMs = Date.now();const date = new Date(epochSeconds * 1000);
const iso = date.toISOString(); // "2024-01-15T12:00:00.000Z"const epochSeconds = Math.floor(new Date("2024-01-15T12:00:00Z").getTime() / 1000);Why Unix time?
When you need to store a moment in time — a log entry, a database row, an API response — the simplest and most portable representation is a single number: the number of seconds (or milliseconds) since midnight on January 1, 1970 UTC. This is the Unix timestamp, sometimes called epoch time or POSIX time.
The advantage over storing a formatted string like "2024-01-15 12:00:00" is that a number has no ambiguity: it does not depend on a time zone, a locale, or a format. Sorting by timestamp means sorting numerically. Calculating the difference between two moments is a subtraction. Any programming language can read it without a special parser.
The main thing to watch out for is the seconds vs milliseconds distinction. JavaScript and Java work natively in milliseconds;Python, Go, Unix shell tools, and most databases work in seconds. Always be explicit about which unit you are using — a 13-digit number passed where a 10-digit one is expected will produce a date in the year 56000.
Common pitfalls
- Mixing seconds and milliseconds. A common bug is passing
Date.now()(ms) directly to an API that expects seconds, or vice versa. The result is a timestamp 1,000× too large or too small. - Using local time instead of UTC.Functions like Python's
datetime.now()(no timezone) or .NET'sDateTime.Nowreturn local time. Always use UTC-aware equivalents for timestamps that will be stored or transmitted. - Integer overflow in 32-bit systems. A 32-bit signed integer can only represent Unix timestamps up to January 19, 2038 (the Y2K38 problem). Use 64-bit integers for all timestamp storage.
- Forgetting time zone on parse. Parsing
"2024-01-15 12:00:00"without specifying a time zone produces a local-time result in most languages. Always include the offset or specify UTC explicitly.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds (or milliseconds) that have elapsed since January 1, 1970 at 00:00:00 UTC — a reference point called the Unix epoch. It is the most portable way to store or transmit a point in time across programming languages and systems, because it is just a number with no time zone ambiguity.
Should I store timestamps in seconds or milliseconds?
Use seconds when interfacing with POSIX APIs, shell tools, databases like PostgreSQL's to_timestamp(), or any system that explicitly expects seconds. Use milliseconds when working in JavaScript (Date.now() returns ms by default), Redis TTLs, or systems that need sub-second precision without a floating-point type. When in doubt, store milliseconds — it is easy to truncate to seconds, and you lose no precision.
How do I know whether a number is seconds or milliseconds?
Count the digits. A 10-digit number (around 1,700,000,000) is seconds and represents a date in the 2020s. A 13-digit number (around 1,700,000,000,000) is milliseconds for the same period. The main converter on this site auto-detects the unit using this heuristic.
Why does multiplying a Unix timestamp by 1000 give the milliseconds version?
A second contains exactly 1,000 milliseconds. If you have a Unix second value, multiplying by 1,000 gives the number of milliseconds since the epoch. Most languages that work in milliseconds internally (like JavaScript) require this conversion when reading a second-precision value from a server or database.
Are these snippets safe across time zones?
Yes — all snippets target UTC. The key is using UTC-aware functions: time.time() in Python, Instant.now() in Java/Kotlin, DateTimeOffset.UtcNow in .NET, Date.now() in JavaScript. These return a number of seconds/milliseconds since the UTC epoch, which is the same value regardless of the machine's local time zone. Avoid non-UTC equivalents like DateTime.Now in .NET or localtime() in C unless you explicitly need local-time arithmetic.
Does Rust need the chrono crate for timestamp conversion?
For getting the current Unix time, Rust's standard library is sufficient: SystemTime::now().duration_since(UNIX_EPOCH). For parsing ISO 8601 strings and formatting dates, the chrono crate is the practical choice — the standard library has no built-in date formatting. Add it with: chrono = "0.4" in Cargo.toml.