Why Convert a Date to a Unix Timestamp?
Dates as strings are human-readable but awkward for computers. Comparing "2024-06-01" to "2023-12-15" requires a parser. Storing them in a database takes more bytes and makes indexing slower. Unix timestamps — plain integers — solve all of this. Comparing two timestamps is an integer comparison. Sorting a column of timestamps is trivially fast. Arithmetic like "add 30 days" is just adding 2,592,000 to the integer. This is why most backend systems, APIs, and databases prefer timestamps to date strings.
Timezone Gotchas When Converting
The most dangerous mistake when converting a date to a timestamp is treating a local date as UTC. If you call new Date("2024-06-01") in a browser running in Pacific Time (UTC-7), JavaScript parses it as 2024-06-01T07:00:00Z — not midnight UTC. The timestamp you get back will be 7 hours ahead of what you intended.
To get midnight UTC reliably: use new Date("2024-06-01T00:00:00Z") — always append the Z suffix. Without it, date-only strings are parsed as local time in most browsers (per the ECMAScript spec, which changed between ES5 and ES6 and is still inconsistently implemented).
In Python, always pass tzinfo=timezone.utc to datetime.fromisoformat() or datetime.strptime(). Naive datetimes (without tzinfo) will produce incorrect timestamps when your server's system timezone is not UTC.
Common Date Formats This Tool Accepts
This converter uses the browser's built-in Date parser, which accepts a wide range of formats:
2024-06-01— ISO date (parsed as local midnight in most browsers)2024-06-01T00:00:00Z— ISO datetime with UTC suffix (recommended)June 1, 2024— human-readable (locale-dependent, avoid in code)2024-06-01T12:30:00+05:30— ISO with offset (safe and explicit)
Quick Reference
// JavaScript — safe UTC conversion
Math.floor(new Date('2024-06-01T00:00:00Z').getTime() / 1000);
// → 1717200000
// Python
from datetime import datetime, timezone
dt = datetime.fromisoformat('2024-06-01T00:00:00+00:00')
int(dt.timestamp()) # → 1717200000
// SQL (PostgreSQL)
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2024-06-01 00:00:00 UTC')::bigint;
-- → 1717200000 Frequently Asked Questions
Why does my date convert to the wrong timestamp?
The most common cause is timezone ambiguity. If you enter '2024-06-01' without a timezone suffix, the browser parses it as local midnight. For UTC midnight, always use '2024-06-01T00:00:00Z' with the Z suffix. The tool shows the parsed UTC string so you can verify.
What date formats does this converter accept?
This tool uses the browser's built-in Date parser. It reliably accepts ISO 8601 formats (2024-06-01, 2024-06-01T12:00:00Z, 2024-06-01T12:00:00+05:30). Human-readable formats like 'June 1, 2024' usually work but are locale-dependent and should be avoided in production code.
How do I get the current Unix timestamp in JavaScript?
Use Math.floor(Date.now() / 1000) for seconds or Date.now() for milliseconds. The .now() method is faster than creating a new Date() object because it skips Date construction and returns the raw integer directly.
How do I convert a date to a timestamp in Python?
Use datetime.fromisoformat('2024-06-01T00:00:00+00:00').timestamp() and cast to int. Always include timezone info in the string — naive datetimes without tzinfo give incorrect results when the server timezone is not UTC.
What is the difference between Unix seconds and JavaScript milliseconds?
Unix time is defined in seconds — a 10-digit integer for recent dates. JavaScript's Date internally tracks milliseconds — a 13-digit integer. When calling new Date(timestamp), multiply seconds by 1000. When reading Date.getTime(), divide by 1000 to get seconds. Forgetting this multiplication or division is one of the most common JavaScript time bugs.