Date Conversion to Epoch Time: How It Works

Date conversion to epoch time turns a calendar date and time into a single integer: the number of seconds (or milliseconds) elapsed since January 1, 1970, 00:00:00 UTC, not counting leap seconds. You enter a date and time, optionally with a time zone, and get back that integer, which is how most computers store and compare timestamps. This page explains the conversion formula, shows a worked example, and covers the common pitfalls like time zones and the year 2038 problem.

Formula

The conversion uses the standard Unix epoch definition:

epoch seconds = (days since 1970-01-01) × 86400 + (seconds since midnight) − (time zone offset × 3600)

Where:

• days since 1970-01-01 – the number of whole days from the epoch date to the given date, using the proleptic Gregorian calendar (the standard calendar extended backward).
• 86400 – the number of seconds in one day (24 × 60 × 60).
• seconds since midnight – HH × 3600 + MM × 60 + SS from the time part.
• time zone offset – the difference from UTC in hours; positive for east of UTC (e.g., UTC+2), negative for west (e.g., UTC−5).

Leap seconds are ignored in Unix time – each day is treated as exactly 86,400 seconds. This is the convention used by POSIX systems and most programming languages.

Worked Example

Using the default input: 2024-06-15 12:30:00 UTC (offset 0).

1. Days from 1970-01-01 to 2024-06-15: 19,884 days (calculated by counting leap years and days per month).
2. Seconds from days: 19,884 × 86,400 = 1,718,697,600.
3. Seconds from time: 12 × 3600 + 30 × 60 + 0 = 45,000.
4. Add: 1,718,697,600 + 45,000 = 1,718,742,600.
5. Subtract time zone offset: 0 × 3600 = 0, so result is 1,718,742,600.

That is the epoch time for the given date in UTC. If you change the offset to +2, the result becomes 1,718,735,400 (two hours earlier in UTC).

Why 1970? The Background

The Unix epoch was chosen by early Unix developers in the late 1960s and early 1970s. The date January 1, 1970, was a convenient, round starting point that aligned with the release of the first Unix system. It was not arbitrary – it allowed time to be stored as a simple 32-bit integer counting seconds, which was efficient and easy to compare. Before Unix, different systems used different epochs (e.g., 1900 or 1960), causing compatibility headaches. The Unix epoch became the de facto standard because Unix spread widely, and later standards like POSIX formalized it. Today, it is used not only in Unix-like systems but also in Windows (as a separate epoch), Java, JavaScript, Python, and virtually every programming language.

How the Conversion Works in Practice

When you convert a date to epoch time, the process always goes through UTC. The steps are:

1. Parse the date and time into its components (year, month, day, hour, minute, second).
2. Determine the time zone offset from UTC for that specific moment – this may involve daylight saving time rules, which change the offset depending on the date.
3. Convert the local time to UTC by subtracting the offset.
4. Calculate the number of days between the UTC date and the epoch, then multiply by 86,400 and add the seconds since midnight.

Most programming languages have built-in functions for this (e.g., Date.UTC() in JavaScript, time.mktime() in Python, mktime() in C). The calculator above simplifies the time zone part by asking for a fixed offset, which works for standard time but not for daylight saving transitions.

Choosing the Right Epoch: Seconds vs. Milliseconds

While the classic Unix time is in seconds, many modern systems use milliseconds for higher precision. For example:

• JavaScript’s Date.now() returns milliseconds since the epoch.
• Java’s System.currentTimeMillis() also uses milliseconds.
• Databases like PostgreSQL store timestamps in microseconds (since 2000-01-01 in some contexts).

When converting, be aware of the unit. A value like 1718742600 could be seconds (May 2024) or milliseconds (January 1970). Always check the expected unit in your system. The calculator above outputs seconds; to get milliseconds, multiply by 1000.

Common Problems and Mistakes

The most frequent errors in date-to-epoch conversion are:

• Time zone confusion – forgetting to convert local time to UTC. If you treat a local time as UTC, the epoch value is off by the offset (e.g., 5 hours for US Eastern).
• Daylight saving time – using a fixed offset when the region observes DST. For example, New York is UTC−5 in winter and UTC−4 in summer. A hardcoded offset will be wrong for half the year.
• Leap seconds – most systems ignore them, but some precise applications (like astronomical) need to account for them. The official Unix time does not include leap seconds, so a day with a leap second still has 86,400 seconds.
• Year 2038 problem – on 32-bit systems, the maximum signed integer is 2,147,483,647, which corresponds to 2038-01-19 03:14:07 UTC. After that, the integer overflows. Most modern systems use 64-bit integers, but older embedded systems may still be affected.
• Date parsing ambiguity – formats like “06/15/2024� can be interpreted as June 15 or 6 May depending on locale. Always use unambiguous formats like ISO 8601 (YYYY-MM-DD).

Alternatives and Related Notions

While Unix epoch time is dominant, other systems exist:

• Excel serial dates – count days since 1900-01-00 (with a quirk for 1900).
• Julian day number – counts days since 4713 BC, used in astronomy.
• NTP time – counts seconds since 1900-01-01, used in network time protocol.
• ISO 8601 strings – human-readable format like “2024-06-15T12:30:00Z� which is often converted to epoch internally.

For most developers, the Unix epoch is the lingua franca because it is simple, compact, and time-zone independent. When storing timestamps, using UTC-based epoch avoids ambiguity across servers and users.

How to Read the Result

The epoch number itself is not human-friendly, but it is easy to interpret with tools. A quick mental check: 1,000,000,000 seconds is roughly November 2001. The current epoch time (as of 2025) is around 1.75 billion seconds. If you get a number like 1,700,000,000, it is in 2023–2024. To convert back, you can use the reverse formula: divide by 86,400 to get days, then add to 1970-01-01. Many online converters and programming functions do this automatically.

Frequently Asked Questions

What is the epoch time for January 1, 1970?

It is 0 seconds. That is the definition: the epoch is the starting point, so any date before that gives a negative number.

How do I convert a date with a time zone like “2024-06-15 12:30:00 EDT� to epoch?

First, determine the UTC offset for that date and time. EDT is UTC−4, so subtract 4 hours from 12:30 to get 08:30 UTC. Then convert that to epoch using the formula. The result is 1,718,742,600 − 4 × 3600 = 1,718,728,200.

Why do some epoch values have 13 digits instead of 10?

Those are in milliseconds, not seconds. For example, 1,718,742,600,000 is the same moment as 1,718,742,600 seconds. Always check the unit before using the value.

What happens if I enter a date before 1970?

The calculator gives a negative number, which is correct. For instance, 1969-12-31 23:59:59 UTC is −1 second. Negative epoch values are valid and used for historical timestamps.

Does the calculator handle daylight saving time?

No, it uses a fixed offset you provide. For DST, you must adjust the offset manually based on the date. For example, for New York in July, use −4; in January, use −5.

What is the year 2038 problem?

It is the overflow of 32-bit signed integers storing epoch seconds. On January 19, 2038, at 03:14:07 UTC, the value reaches 2,147,483,647 and cannot go higher. Systems using 64-bit integers will not have this issue, but older software might fail.

Related

• Time Speed Up Calculator: Does It Exist?
• Time Calculator From Speed and Distance
• Time Clock Converter Calculator: How It Works

in dt | Date and time (YYYY-MM-DD HH:MM:SS) | - | 2024-06-15 12:30:00 | 0
in tz | Time zone offset from UTC (hours) | h | 0 | -12
out epoch | Epoch seconds | s | epoch_from_datetime(dt, tz) | 0