Unix timestamp calculator

Add or subtract an interval, measure the gap between two epochs, or round an instant down to the start of a day, week, month or year in the timezone you actually care about. Three calculations that a bare + 86400 gets wrong in three different ways.

The three calculations

Unix time is a plain count of seconds since 1970-01-01T00:00:00Z, which makes some timestamp arithmetic trivial and the rest quietly treacherous. Subtracting two epochs is exact and always has been. Adding a month is not arithmetic at all. And "the start of today" is not a property of the timestamp — it is a question about a timezone. This page keeps those three apart:

Every input accepts the same things the rest of the site does: 10-digit seconds, 13-digit milliseconds, or a date string. If you are not sure which unit you are holding, check the digit count first — an interval added to a millisecond value in seconds lands a thousand times short of where you meant.

Adding and subtracting intervals

The multipliers are worth memorising, because they are all this mode does: a minute is 60 seconds, an hour 3600, a day 86400, a week 604800. Adding 90 days to 1787184000 is adding 90 × 86400 = 7776000, which lands on 1794960000. 

// 90 days after 2026-08-20T00:00:00Z
1787184000 + (90 * 86400)   // 1794960000 -> 2026-11-18T00:00:00Z

// the same shift on a millisecond timestamp
1787184000000 + (90 * 86400 * 1000)

Months and years are deliberately not offered. A month is 28, 29, 30 or 31 days, so any seconds-per-month constant is wrong most of the year, and a calculator that hides that behind "1 month = 2592000" produces answers that are plausible and incorrect — the same failure shape as a date that renders as January 1, 1970. Calendar-relative arithmetic belongs in your language's date library; elapsed-time arithmetic belongs here.

The difference between two timestamps

This one is exact, and it is the reason to store epoch seconds in the first place: because a Unix timestamp carries no timezone and no calendar, subtracting one from another gives the true elapsed seconds between the two instants, with no daylight-saving correction and no locale in the way. The mode reports both the raw signed difference and a readable breakdown, and a negative result simply means the second value is the earlier one.

The most-asked instance of this question on this site is how long is left before the signed 32-bit clock overflows — the answer is a difference against 2147483647, and the year 2038 page explains what happens on the other side of it. For a difference against right now, start from the live epoch clock.

Rounding to the start of a day, week or month

Writing WHERE created_at >= … needs a boundary, and the tempting one-liner is wrong outside UTC: 

// midnight UTC, whatever your users' clocks said
ts - (ts % 86400)

// what you usually meant: midnight where the reader is
startOfDay(ts, 'Asia/Kolkata')

A boundary is a civil-time idea, so this mode converts the instant to wall-clock time in the zone you choose, truncates it to the day, week, month or year, and converts the result back to epoch seconds. Weeks start on Monday, per ISO 8601, so a weekend stays in one week. If the zone you need is the question rather than the input, read the instant in that zone first.

Daylight saving is the part that catches everyone. On the morning a zone springs forward, the offset at the instant you entered and the offset at that day's midnight are different numbers, so the boundary has to be resolved against the offset in force at the boundary — this page does that in two passes rather than one. It matters for exactly the queries where being an hour out is hardest to notice. If you are rounding a whole column rather than one value, paste the column into the bulk converter instead.

Frequently asked questions

How do I add days to a Unix timestamp?

Multiply the number of days by 86,400 and add it to the timestamp: a day is 86,400 seconds, an hour 3,600, a minute 60. Adding 90 days to 1787184000 means adding 7,776,000, which gives 1794960000. If your value is a 13-digit millisecond timestamp, multiply the interval by 1000 as well, or the shift lands a thousand times short.

Why can I not add one month to a Unix timestamp?

Because a month is not a fixed number of seconds. February is 28 or 29 days and the months around it are 30 or 31, so any single seconds-per-month constant is wrong for most of the year. This calculator offers seconds, minutes, hours, days and weeks — all of which are exact — and handles calendar arithmetic in the round-down mode instead, where the boundary is resolved against a real calendar.

How do I get the number of seconds between two dates?

Subtract the earlier Unix timestamp from the later one; the result is the elapsed seconds, because Unix time is a count of seconds with no timezone or calendar in it. The difference mode does that subtraction and also breaks the result into days, hours, minutes and seconds. A negative result means the second value is the earlier one.

What is the start of today as a Unix timestamp?

It depends on the timezone you mean it in. Rounding with timestamp minus timestamp modulo 86400 gives midnight UTC, which is the wrong instant for every reader outside UTC. The round-down mode converts the instant to wall-clock time in the zone you pick, truncates it to the day, week, month or year, and converts back — so the value is the midnight your users actually saw.

Does rounding handle daylight saving time?

Yes. The offset in force at the instant you entered and the offset in force at the boundary can differ on the day a zone changes clocks, so the boundary is resolved twice: once with the offset at the instant, then again with the offset at the candidate boundary if the two disagree. Computing both with a single offset is the standard version of this bug and lands an hour off twice a year.