Datetime to Unix Timestamp
Turn an ISO 8601 date-time into Unix epoch seconds and milliseconds, with time-zone rules, a worked 2026 example and the seconds-versus-milliseconds trap.
Results
Unix timestamp (s)
- Milliseconds
- 1789473600000
You might also need
Educational estimates · not financial advice · free, no signup
Formula / how it works
Unix seconds = floor(UTC milliseconds of parsed instant ÷ 1000). Prefer ISO-8601 with timezone.
Detailed guide
What it is, how to use it, how to read the numbers, common mistakes, a worked example, formulas, and FAQs.
What this calculator is
A Unix timestamp counts the seconds since 1 January 1970 at 00:00:00 UTC, ignoring leap seconds. It is the common way to store a moment in APIs, logs and databases because it is a single number with no time zone. This tool parses a date-time string, usually in ISO 8601 form, and returns the timestamp in seconds and in milliseconds. The most important detail is the time zone. 2026-09-15T12:00:00Z means noon UTC, while the same text without the Z is parsed in your local time zone and gives a different timestamp. Timestamps in seconds have ten digits today; JavaScript and many APIs use milliseconds, which have thirteen.
When to use / who it helps
- You need an epoch value for an API call or database query.
- You are debugging logs with timestamps.
- You want to schedule something with a cron-like system.
- You need to compare moments across time zones.
- You are generating test data.
How to use
Steps
- Type the date-time in ISO 8601 form, for example 2026-09-15T12:00:00Z.
- Include Z or an offset such as +05:30.
- Read the timestamp in seconds.
- Read the milliseconds value if your system needs it.
- Convert back with a timestamp-to-date tool to confirm.
- Check whether the target system expects seconds or milliseconds.
How to interpret results
- The result is the same instant regardless of time zone.
- Seconds are ten digits for dates between 2001 and 2286.
- Milliseconds are the seconds value times 1,000.
- Without a zone, the date-time is read in local time.
- Dates before 1970 give negative timestamps.
Common mistakes & gotchas
- Leaving off the time zone.
- Mixing seconds and milliseconds.
- Using a non-standard date string that parses differently across browsers.
- Forgetting that daylight saving time shifts local offsets.
- Expecting leap seconds to be included.
Worked example
Worked example — 15 September 2026 12:00 UTC
- 1 January 2026 00:00:00Z is 1,767,225,600 seconds after the epoch.
- 1 January to 15 September is 257 days, which is 257 × 86,400 = 22,204,800 seconds.
- Add 12 hours: 43,200 seconds. Total: 1,767,225,600 + 22,204,800 + 43,200 = 1,789,473,600.
- In milliseconds this is 1,789,473,600,000. The same instant written as 2026-09-15T17:30:00+05:30 gives the same value.
Result: 2026-09-15T12:00:00Z is 1,789,473,600 in Unix seconds.
To load the form's own demo values, tap Try example above the Calculate button.
How to calculate / formula
Unix seconds = floor(UTC milliseconds of parsed instant ÷ 1000). Prefer ISO-8601 with timezone.
Frequently asked questions
What is a Unix timestamp?
The number of seconds since 1 January 1970 00:00:00 UTC.
Why are some timestamps 13 digits?
They are in milliseconds.
Does the timestamp depend on time zone?
No. It identifies one instant; only the way you write it depends on the zone.
What happens if I omit the time zone?
The string is read in your local zone and may give a different result.
What is the Year 2038 problem?
Signed 32-bit timestamps overflow on 19 January 2038.
Can timestamps be negative?
Yes, for moments before 1970.