Converting a calendar date to a Unix timestamp, by hand
Going from a calendar date to a Unix timestamp is the reverse of reading one: instead of dividing a count of seconds to find a date, you count the days to a date and multiply. One multiplication, once you know how many days have actually passed since 1 January 1970.
The method
- Count the number of full years between 1970 and the year before your target date, adding 366 for each leap year and 365 for every other year.
- Add the number of days elapsed in the target year itself, from 1 January up to (but not including) the target date.
- Multiply the total day count by 86,400 (the number of seconds in a day: 60 × 60 × 24) to get the Unix timestamp in seconds, at midnight UTC on that date.
- Multiply by 1,000 again if you need milliseconds, which is what most logging libraries and JavaScript expect.
A worked example
Target date: 16 October 2026, midnight UTC.
Full years from 1970 through 2025 is 56 years. Of those, the leap years (divisible by 4, except century years not divisible by 400) are 1972, 1976, …, 2024 — 14 of them. So days through the end of 2025: (56 − 14) × 365 + 14 × 366 = 42 × 365 + 14 × 366 = 15,330 + 5,124 = 20,454 days.
Days elapsed in 2026 up to 16 October: January through September is 31 + 28 + 31 + 30 + 31 + 30 + 31 + 31 + 30 = 273 days, plus 15 more days into October (the 16th hasn't started yet at midnight), giving 273 + 15 = 288 days.
Total days since the epoch: 20,454 + 288 = 20,742 days.
Multiply by 86,400: 20,742 × 86,400 = 1,792,108,800 seconds. In milliseconds: 1,792,108,800 × 1,000 = 1,792,108,800,000.
The mistake worth watching for
The usual slip is counting the target date itself as an elapsed day. At midnight on 16 October, only 15 days of October have fully passed — the 16th is the day that is just beginning, not a day already completed. The same off-by-one applies at the year boundary: 2026 isn't a "full year" yet when you're still inside it, so it's never added to the full-years total, only its elapsed days are.
Seconds and milliseconds are the other common mix-up — a value three orders of magnitude off a correct seconds timestamp is almost always a missing or extra factor of 1,000, not a wrong date.
Nothing is uploaded; the free Date → Timestamp tool does this same day-count-then-multiply arithmetic in your browser and shows both the seconds and milliseconds value side by side.