Date to Unix Timestamp Converter
Enter a calendar date and clock time in any time zone and get the epoch value in seconds and milliseconds. Daylight saving transitions are resolved using your browser’s IANA time zone database, and impossible or ambiguous local times are flagged rather than guessed at silently.
Convert a date and time
Current Unix time
The counter above ticks once per second and comes from your own device clock. If it looks wrong, your system clock is wrong.
How a local date becomes an epoch number
Going from a timestamp to a date is a one-way calculation. Going the other direction is harder, because a local wall-clock time is not by itself a unique instant — it only becomes one once you attach a time zone, and the offset that zone applies depends on the very date you are trying to convert.
The sequence is:
- Interpret your six fields (year, month, day, hour, minute, second) as a naive wall-clock time.
- Ask the time zone database what offset the selected zone was using at approximately that moment.
- Subtract that offset to get UTC, then re-check: the shift may have moved the instant across a DST boundary, in which case the offset is recomputed and applied again. Two passes always converge.
- Divide by 1,000 for seconds.
Step 3 is the part naive implementations skip. Adding a hard-coded offset — treating "Berlin" as permanently UTC+1 — gives an answer that is wrong by an hour for roughly half the year, and wrong by more than that for dates before the modern rules were adopted.
The two awkward cases
Times that do not exist. When clocks spring forward, an hour of local time is skipped. In New York on 10 March 2024, the clock goes straight from 01:59:59 to 03:00:00 — so 02:30 that morning never happened. Enter it here and the tool moves the instant past the gap and tells you it did.
Times that happen twice. When clocks fall back, an hour repeats. 01:30 on 3 November 2024 in New York occurs once at UTC−4 and again an hour later at UTC−5. There is no correct answer without more information, so the tool takes the earlier instant and displays a warning so you know a choice was made on your behalf.
If you need to be certain which one you meant, switch the zone selector to UTC and enter the UTC time directly — that is always unambiguous.
Worked examples
The start of a billing period
You need the epoch value for midnight on 1 March 2024, Berlin time. Set the zone to Europe/Berlin and enter 2024-03-01 00:00:00:
Unix seconds 1709247600
Same instant UTC 2024-02-29T23:00:00ZBerlin was on CET (UTC+1) in March, so local midnight is 23:00 the previous day in UTC — and 2024 being a leap year, that previous day is 29 February. Two easy mistakes avoided in one conversion.
The Unix epoch itself
Set the zone to UTC and enter 1970-01-01 00:00:00. The result is 0, by definition. Now switch the zone to Asia/Tokyo without touching the fields: the same local wall clock now yields -32400, because midnight in Tokyo was nine hours before midnight UTC. This is the clearest demonstration of why a date without a zone is not an instant.
A date before 1970
Enter 1969-12-31 00:00:00 in UTC and you get -86400 — negative, and exactly one day’s worth of seconds. Historical dates work the same way: 1 January 1900 in UTC is -2208988800. If a system you are feeding rejects negative values, that is a limitation of that system, not of the timestamp.
Questions
Which time zone do the date fields use?
Whichever one is selected in the picker above the fields — by default your browser’s own zone. Change the selector and the fields keep their values while the resulting timestamp changes, which is usually what you want when converting between offices.
Why is the resulting UTC date one day off from what I entered?
That is expected near midnight. A local time close to 00:00 in a zone ahead of UTC falls on the previous UTC day, and a local time close to 23:59 in a zone behind UTC falls on the next one. The "Same instant in UTC" output is shown precisely so this is visible rather than surprising.
Does it accept dates before 1970 or beyond 2038?
Both. Enter any year from about 271,821 BC to 275,760 AD. There is no 32-bit limit here — the year 2038 problem is a property of systems that store time_t in a signed 32-bit integer, not of the timestamp concept. The output for dates past 2038 is a perfectly ordinary number that a 64-bit system will handle fine.
What happens if I enter 31 February?
You get an explicit error naming the month and year, rather than a silently rolled-over date. Many date libraries quietly turn 31 February into 2 or 3 March, which hides data-entry bugs; this tool refuses instead.
Should I store local time or UTC in my database?
Store the instant — either an epoch integer or a UTC timestamp with an explicit zone. Store local wall-clock strings only when the local time is the meaningful thing (a 09:00 recurring alarm should stay at 09:00 through a DST change), and in that case store the IANA zone identifier alongside it. Never store a bare local datetime with no zone information; the offset cannot be reconstructed later.
Can I convert a whole column of dates at once?
Batch mode on the main converter handles many timestamps at once in the timestamp-to-date direction. For bulk date-to-timestamp work, a spreadsheet formula is usually the better tool: in most spreadsheet software, (A1 - DATE(1970,1,1)) * 86400 gives epoch seconds for a UTC date in cell A1.