How a date becomes a timestamp
A date such as 1 January 2024, 00:00 means different moments in different places, so a time zone is needed before it can become a number. The converter first works out the offset from UTC that applied in your chosen zone at that date and time, then counts the seconds from 1 January 1970 00:00:00 UTC to that moment.
| Date and time | Time zone | Unix timestamp |
|---|---|---|
| 2024-01-01 00:00:00 | UTC | 1704067200 |
| 2024-01-01 00:00:00 | New York (UTC-5) | 1704085200 |
| 2024-01-01 00:00:00 | Tokyo (UTC+9) | 1704034800 |
| 2025-01-01 00:00:00 | UTC | 1735689600 |
| 2000-01-01 00:00:00 | UTC | 946684800 |
The same wall-clock time gives three different timestamps, because midnight in Tokyo came 14 hours before midnight in New York.
Two ways to enter a date
- The boxes. Year, month, day, hour, minute, second and millisecond. Empty time boxes count as zero. The month is 1 to 12, not 0 to 11 as in JavaScript code.
- Paste a date. Accepts
YYYY-MM-DD,YYYY-MM-DD HH:MM:SSand ISO 8601 such as2024-06-15T09:30:00.250Z. If the text ends withZ,UTCor an offset like+02:00, that offset is used and the time zone box is ignored. Otherwise the time is read in the zone you chose.
Daylight saving time
Zones that change their clocks have two special cases, and the page warns you about both:
- A time that does not exist. When clocks jump forward, an hour is skipped. In New York on 10 March 2024, 02:30 never happened. The result is the nearest valid moment and a notice is shown.
- A time that happens twice. When clocks go back, an hour repeats. In New York on 3 November 2024, 01:30 occurred twice, one hour apart. If a clock change is near your time, check which of the two moments you mean, or enter the offset (for example
-04:00) in the pasted date to be exact.
The safest way to avoid this is to store and exchange times in UTC, or as timestamps, and to convert to a time zone only for display.
Convert a date to a timestamp in code
// JavaScript (the string ends in Z, so it is UTC)
Math.floor(Date.parse('2024-01-01T00:00:00Z') / 1000); // 1704067200
# Python
from datetime import datetime, timezone
int(datetime(2024, 1, 1, tzinfo=timezone.utc).timestamp())
// PHP
strtotime('2024-01-01 00:00:00 UTC');
// Java
Instant.parse("2024-01-01T00:00:00Z").getEpochSecond();
// C#
new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero).ToUnixTimeSeconds();
// Go
time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC).Unix()
# Shell (GNU date)
date -u -d '2024-01-01 00:00:00' +%s
In a database or a spreadsheet
-- MySQL (the string is read in the session time zone)
SELECT UNIX_TIMESTAMP('2024-01-01 00:00:00');
-- PostgreSQL
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2024-01-01 00:00:00+00');
-- SQLite
SELECT strftime('%s', '2024-01-01 00:00:00');
=(A1 - DATE(1970, 1, 1)) * 86400 (Excel and Google Sheets, A1 holds a UTC date)
Common mistakes
- Parsing a date without a zone.
new Date('2024-01-01 00:00:00')is read in the local zone of the machine, so two servers give two answers. AddZor an offset. - Zero-based months. JavaScript's
new Date(2024, 0, 1)is January. In this tool, January is 1. - Forgetting milliseconds. JavaScript and Java use milliseconds. Multiply seconds by 1000 for them.
To go back, use timestamp to date. For both directions on one page, open the Unix timestamp converter. Background is in What is Unix time?