1704067200 is January 1, 2024, 00:00:00 UTC, or December 31, 2023, 7:00 PM in New York
A Unix timestamp (Unix time, epoch time) is the number of seconds that have passed since 00:00:00 UTC on January 1, 1970, which counts as 0. The number 1704067200 is January 1, 2024, 00:00:00 UTC. New York is five hours behind UTC in winter, so the same moment is 7:00 PM on December 31, 2023 there. The 13-digit number 1704067200000 is the same moment counted in milliseconds.
Paste a number into the converter above and it picks seconds, milliseconds, microseconds or nanoseconds from the digit count and turns it into a date. Enter a date and time and it works backward to the number. Pick a time zone and it applies that place's daylight saving time and old standard times. The strip at the top shows the current Unix time, updated every second, and the number line below shows whether your value fits in a 32-bit integer.
Why time is stored as one number, and when you need to convert it
A written date such as "January 1, 2024, 7:00 PM" only names a moment if you also know the time zone and whether daylight saving time was in effect. A Unix timestamp is the same number everywhere on Earth at the same moment, so servers, databases and APIs use it to pass times around. Subtract two values and you get the seconds between them. Compare them and you know which came first.
The catch is that nobody can read a date from a bare number. You need a conversion in cases like these:
- Reading logs: an error stamped only as 1760000000 has to be turned into your local time before you can line it up with other records.
- Checking an API response or token: the exp, iat and nbf claims in a JSON Web Token (JWT) are NumericDate values defined by RFC 7519, which are seconds since 1970-01-01T00:00:00Z. Convert one to see whether a token has already expired.
- Querying a range in a database: to find "all of January 1, 2024" in a numeric column you need the timestamps for midnight at the start and end of that day. The "Start and end of the day, month and year" row above gives them.
- Turning a spreadsheet column into dates: if an exported date column holds 10- or 13-digit numbers, you have to pick the unit and time zone and apply a formula (see the Excel section).
- Entering a date as a number: scheduled-send times and expiry settings in many tools take a timestamp, so a specific local time has to be converted first.
How it is calculated: every day is exactly 86,400 seconds
POSIX takes 00:00:00 UTC on January 1, 1970 as the Epoch and counts every day since then as exactly 86,400 seconds. Turning a date into a number is therefore: days from the Epoch up to that day, times 86,400, plus the seconds since midnight of that day.
- Convert the date and time to UTC: in New York in winter, add 5 hours. December 31, 2023, 19:00 in New York is January 1, 2024, 00:00 UTC.
- Count the days from January 1, 1970 up to that day: 1970 to 2023 is 54 years × 365 days = 19,710 days, plus one extra day for each of 13 leap years (1972, 1976, …, 2020), which makes 19,723 days.
- Multiply the days by 86,400 and add hours × 3,600 + minutes × 60 + seconds: 19,723 × 86,400 + 0 = 1,704,067,200 seconds.
- Match the unit: multiply by 1,000 for milliseconds, 1,000,000 for microseconds and 1,000,000,000 for nanoseconds.
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400POSIX.1-2024 4.19 Seconds Since the Epoch (the formula for dates after 1970, with integer division). The same section says "each and every day shall be accounted for by exactly 86400 seconds".
To go from a number to a date, divide by 86,400 instead. 1,704,067,200 ÷ 86,400 = 19,723 with remainder 0, so it is 19,723 days after January 1, 1970: January 1, 2024, 00:00:00 UTC. The converter does this arithmetic with large integers down to the nanosecond, then adds the real offset for the time zone you chose using the browser's IANA time zone data.
Telling the unit from the digit count: 10, 13, 16 and 19 digits
A timestamp does not say what unit it uses. One moment is 10 digits in seconds and 13 digits in milliseconds. For present-day dates, the digit counts and the converter's automatic rules are:
| Unit | Value | Digits | Auto-detect (integer part) | Commonly used by |
|---|---|---|---|---|
| Seconds (s) | 1704067200 | 10 | Below 100 billion (1011) | PHP time(), MySQL UNIX_TIMESTAMP(), JWT, date +%s |
| Milliseconds (ms) | 1704067200000 | 13 | 1011 up to below 1014 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microseconds (µs) | 1704067200000000 | 16 | 1014 up to below 1017 | Go UnixMicro() |
| Nanoseconds (ns) | 1704067200000000000 | 19 | 1017 and above | Python time.time_ns(), Go UnixNano() |
With these cutoffs, every moment from March 3, 1973, 09:46:40 UTC to November 16, 5138, 09:46:40 UTC is read correctly whichever unit it was written in. Numbers below a cutoff, such as millisecond values from 1970 to early March 1973, are read as the next smaller unit. If you know the source unit, choose it in "Unit". Unusual digit counts such as 11, 14 or 17 get a note asking you to double-check.
Reading the wrong unit throws the date far off. 1704067200 read as milliseconds becomes January 20, 1970, 17:21:07.200 UTC, and 1704067200000 read as seconds lands around the year 55,970, which is outside this converter's range (year 9999). If dates pile up in January 1970 or the converter says the value is outside the 0001–9999 range, check the unit first.
Worked examples
| Input | Unit | UTC | New York |
|---|---|---|---|
| 0 | seconds | 1970-01-01 00:00:00 | 1969-12-31 19:00:00 |
| -1 | seconds | 1969-12-31 23:59:59 | 1969-12-31 18:59:59 |
| 1704085200 | seconds | 2024-01-01 05:00:00 | 2024-01-01 00:00:00 |
| 1704067200 | seconds | 2024-01-01 00:00:00 | 2023-12-31 19:00:00 |
| 1704067200.5 | seconds | 2024-01-01 00:00:00.500 | 2023-12-31 19:00:00.500 |
| 1704067200123 | milliseconds | 2024-01-01 00:00:00.123 | 2023-12-31 19:00:00.123 |
| 1704067200123456 | microseconds | 2024-01-01 00:00:00.123456 | 2023-12-31 19:00:00.123456 |
| 1704067200123456789 | nanoseconds | 2024-01-01 00:00:00.123456789 | 2023-12-31 19:00:00.123456789 |
| 1782921600 | seconds | 2026-07-01 16:00:00 | 2026-07-01 12:00:00 (EDT, UTC−4) |
1704085200 is midnight at the start of 2024 in New York. You typed a New York date, yet the UTC column shows 05:00 on the same day, because New York is five hours behind UTC in winter. Both columns name the same moment.
Numbers worth remembering
| Value (seconds) | UTC | New York | Meaning |
|---|---|---|---|
| 0 | 1970-01-01 00:00:00 | 1969-12-31 19:00:00 | The Epoch |
| 1,000,000,000 | 2001-09-09 01:46:40 | 2001-09-08 21:46:40 (EDT) | First 10-digit timestamp (1 billion seconds) |
| 1,234,567,890 | 2009-02-13 23:31:30 | 2009-02-13 18:31:30 | Digits 1 through 0 in order |
| 1,800,000,000 | 2027-01-15 08:00:00 | 2027-01-15 03:00:00 | 1.8 billion seconds (a round 100-million mark) |
| 2,000,000,000 | 2033-05-18 03:33:20 | 2033-05-17 23:33:20 (EDT) | 2 billion seconds |
| 2,147,483,647 | 2038-01-19 03:14:07 | 2038-01-18 22:14:07 | Largest signed 32-bit value (231−1) |
| −2,147,483,648 | 1901-12-13 20:45:52 | 1901-12-13 15:45:52 | Smallest signed 32-bit value |
| 4,294,967,295 | 2106-02-07 06:28:15 | 2106-02-07 01:28:15 | Largest unsigned 32-bit value (232−1) |
Stored in nanoseconds in a signed 64-bit integer, the largest value, 9,223,372,036,854,775,807, is April 11, 2262, 23:47:16.854775807 UTC. The Go documentation says the result of UnixNano() is undefined for dates before the year 1678 or after 2262.
The Year 2038 problem: time in a 32-bit integer
If seconds are stored in a signed 32-bit integer, the largest value is 2,147,483,647, which is January 19, 2038, 03:14:07 UTC (January 18, 10:14:07 PM in New York). The next second does not fit. If the number wraps around to the smallest negative value, −2,147,483,648, the time reads as December 13, 1901, 20:45:52 UTC.
An unsigned 32-bit integer cannot hold negatives, but it runs until February 7, 2106, 06:28:15 UTC. A signed 64-bit integer counting seconds lasts about 292 billion years, which is effectively forever. The two bands in the number line above show these two ranges. A marker outside a band means the value cannot be stored in that format.
Check anywhere that stores 32 bits, such as database columns, file formats and old devices, before entering a future date like a 2040 expiry. The MySQL 8.4 documentation says UNIX_TIMESTAMP() accepts values up to 32536771199.999999 seconds on 64-bit platforms and up to 2147483647.999999 on 32-bit platforms.
Current time and unit in common languages and tools
If you know which program produced a timestamp, you know its unit. The return units below come from each project's official documentation.
| Environment | Code | Unit | Note |
|---|---|---|---|
| JavaScript | Date.now() | milliseconds | 13-digit integer |
| Python | time.time() · time.time_ns() | seconds · nanoseconds | time() is a float with a fraction |
| Java | System.currentTimeMillis() | milliseconds | Precision depends on the operating system |
| PHP | time() | seconds | Carries no time zone |
| Go | time.Now().Unix() · UnixMilli() · UnixNano() | seconds · milliseconds · nanoseconds | UnixNano() only covers 1678 to 2262 |
| MySQL | UNIX_TIMESTAMP() | seconds | A date argument is read in the session time zone; the reverse is FROM_UNIXTIME() |
| PostgreSQL | EXTRACT(EPOCH FROM now()) | seconds | Includes fractional seconds; the reverse is to_timestamp() |
| Shell (GNU date) | date +%s | seconds | The reverse is date -u -d @1704067200 |
| JWT | exp · iat · nbf | seconds | RFC 7519 NumericDate, fractions allowed |
Functions such as MySQL's UNIX_TIMESTAMP('2024-01-01 00:00:00') read the date string in the connection's (session) time zone. The same expression can return values five hours apart on servers set to different zones, so paste the result into this converter to see which moment it meant.
Time zones and daylight saving time
A timestamp holds no time zone. The same 1704067200 shows as 7:00 PM on December 31, 2023 in New York, 4:00 PM in Los Angeles, 6:00 PM in Mexico City and midnight in London, yet it is one moment. A time zone matters only when a number is shown as a clock time that a person reads.
New York has not always been at UTC−5 in winter and UTC−4 in summer either. The IANA time zone database records for America/New_York are below, and the converter uses the offset that applied on the date you enter.
| Period | Standard offset | Summer daylight saving time |
|---|---|---|
| Before November 18, 1883 | −4:56:02 | None (New York local mean time) |
| November 18, 1883 to 2006 | −5:00 | UTC−4 in summer, under US and New York City rules that changed over the years |
| 2007 onward | −5:00 | UTC−4 from the second Sunday of March to the first Sunday of November |
The current US rule is set by federal law. 15 U.S.C. 260a(a) says daylight saving time runs from "2 o'clock antemeridian on the second Sunday of March" to "2 o'clock antemeridian on the first Sunday of November". Because of this, noon on July 1, 2026 in New York is 1782921600. If you used a fixed −5 for every date you would get 1782925200, one hour off.
On March 8, 2026, the clocks jump from 02:00 to 03:00, so 02:00 to 02:59 never happens. On November 1, 2026, 01:00 to 01:59 happens twice. If you enter a time that does not exist, such as 02:30 on March 8, the converter calculates it as 03:30 EDT (1772955000). For a time that occurs twice, such as 01:30 on November 1, it uses the earlier one, in daylight time (1793511000, against 1793514600 for the later one in standard time). It tells you under the field which case applied.
Leap seconds are not counted
To keep clocks in step with the Earth's rotation, 27 leap seconds were added to UTC between 1972 and 2016. Unix time counts every day as exactly 86,400 seconds, so no number stands for a leap second such as 23:59:60 UTC on December 31, 2016. The value after 23:59:59 (1483228799) is 1483228800, which is already 00:00:00 UTC on January 1, 2017.
That means subtracting two timestamps that surround a leap second gives one second less than the time that really passed. The International Earth Rotation and Reference Systems Service (IERS) said in Bulletin C 72 of July 2026 that no leap second will be introduced at the end of December 2026. UTC−TAI has been −37 seconds since January 1, 2017. If you enter 23:59:60 in the time field, you get a note that no such second exists in Unix time.
Converting Unix time in Excel
Excel's 1900 date system stores a date as the number of days since January 1, 1900. To turn seconds into a date, divide by 86,400 and add the serial number of January 1, 1970, which is 25569. With the value in A1, the formulas are:
| Goal | Formula | When A1 = 1704067200 |
|---|---|---|
| Seconds → UTC date | =A1/86400+DATE(1970,1,1) | 45292 → 2024-01-01 00:00:00 |
| Seconds → New York time (standard time) | =A1/86400+DATE(1970,1,1)-5/24 | 45291.7916667 → 2023-12-31 19:00:00 |
| Milliseconds → UTC date | =A1/86400000+DATE(1970,1,1) | With A1 = 1704067200000, 45292 |
| UTC date → seconds | =(A1-DATE(1970,1,1))*86400 | 2024-01-01 00:00 → 1704067200 |
| New York time (standard time) → seconds | =(A1-DATE(1970,1,1)+5/24)*86400 | 2023-12-31 19:00 → 1704067200 |
The result shows as a plain number, so change the cell format to a date and time such as "yyyy-mm-dd hh:mm:ss". In summer, use -4/24 and +4/24 for New York instead of -5/24 and +5/24. A fixed offset cannot follow daylight saving changes, so check older dates or dates near a clock change with this converter. Microsoft says Excel wrongly treats 1900 as a leap year, so serial numbers for dates before March 1, 1900 are a day off from the real calendar. The "Excel / Sheets date value" row above shows nothing for that period.
Common mistakes
- Entering milliseconds as seconds: a 13-digit number in a seconds field lands tens of thousands of years in the future. A 10-digit number read as milliseconds lands in January 1970.
- Applying the time zone twice: a number carries no zone, so the only time to add or subtract hours is once, when turning the number into a clock time. If a log already prints local time as text, converting it again can move the date by a day.
- Forgetting the zone in an Excel formula: =A1/86400+DATE(1970,1,1) gives UTC. For New York you must subtract 5/24 (4/24 in summer), or evening records show the wrong date.
- Putting dates after 2038 in a 32-bit field: if the storage type is a signed 32-bit integer, any value after 03:14:07 UTC on January 19, 2038 overflows.
- Handling nanoseconds as JavaScript numbers: Number cannot hold integers above 253 (9,007,199,254,740,992) exactly, so 1704067200123456789 turns into 1704067200123456800. Keep nanosecond values as strings or BigInt.
Limits
- Only values whose UTC date and chosen-zone date both fall between January 1, 0001 and December 31, 9999 are converted, and digits below a nanosecond are not accepted. Dates before 1582 use today's Gregorian calendar extended backward.
- The leap second moment (23:59:60) cannot be shown, because Unix time has no number for it.
- Times for each zone come from the IANA time zone data inside your browser. A browser with old data may be slow to reflect rule changes in a country that changed recently.
- "Now" and "Difference from now" follow this device's clock, so a wrong clock gives wrong results. The difference from now treats a year as 365.2425 days, so it is approximate.
- "Start and end of the day, month and year" is measured from midnight in the chosen zone. Where midnight is skipped by a daylight saving change, the first time that exists that day is used as the start.
Sources
- 01The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the EpochThe seconds-since-the-Epoch formula and "each and every day shall be accounted for by exactly 86400 seconds". The Epoch is defined in 3.125 (00:00:00 UTC, January 1, 1970)
- 02IETF RFC 7519: JSON Web Token (JWT)Section 2, NumericDate: seconds since 1970-01-01T00:00:00Z, leap seconds ignored, fractions allowed. Sections 4.1.4 to 4.1.6 cover exp, nbf and iat
- 03IETF RFC 3339: Date and Time on the Internet: TimestampsSection 5.6, the date-time format; offsets go only to ±hh:mm (an offset with seconds cannot be written)
- 04IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsThe preferred HTTP date format IMF-fixdate, for example "Sun, 06 Nov 1994 08:49:37 GMT"
- 05ECMAScript: Time Values and Time Range86,400,000 ms per day; range of ±8,640,000,000,000,000 ms (±100 million days)
- 06MDN: Date.now()"returns the number of milliseconds elapsed since the epoch"
- 07Python docs: time.time() and time.time_ns()time() returns seconds since the epoch as a float; time_ns() returns integer nanoseconds. Most Unix systems do not count leap seconds
- 08Go time package: Time.Unix, UnixMilli, UnixMicro, UnixNanoThe result of UnixNano() is undefined for dates before 1678 or after 2262
- 09MySQL 8.4: UNIX_TIMESTAMP() and FROM_UNIXTIME()Returns seconds; date arguments are read in the session time zone; 64-bit platform limit 32536771199.999999 seconds
- 10PostgreSQL: Date/Time Functions, EXTRACT(EPOCH) and to_timestampFor timestamp with time zone, the epoch is seconds since 1970-01-01 00:00:00 UTC (negative before that)
- 11GNU coreutils: Seconds since the EpochA number after "@" is seconds since the epoch; date +%s does not count leap seconds
- 12Microsoft: Excel incorrectly assumes that the year 1900 is a leap yearThe leap-year error in the 1900 date system and the weekday difference before March 1, 1900. The date systems themselves are explained in Microsoft Support, "Date systems in Excel"
- 13IERS Bulletin C 72 (July 6, 2026)"NO leap second will be introduced at the end of December 2026"; UTC−TAI = −37 s from January 1, 2017
- 14IANA time zone database (tzdb) northamericaZone America/New_York: -4:56:02 LMT until 1883 Nov 18 17:00u, then -5:00 with US and NYC rules (NYC rules until 1967); Rule US 2007 on: second Sunday of March, first Sunday of November
- 1515 U.S.C. 260a: Advancement of time or changeover datesSubsection (a): daylight saving time begins "2 o'clock antemeridian on the second Sunday of March" and ends "2 o'clock antemeridian on the first Sunday of November"
Sources checked on 2026-10-18. Time zone data is revised several times a year, and the times on screen follow the version inside the browser you use.
Frequently asked questions
What is the current Unix timestamp?
The "Unix time now" strip at the top shows it, updated every second from this device's clock. Around October 2026 it is a 10-digit number in the 1.79 billion range, and in milliseconds it has three more digits, 13 in all. "Copy seconds" and "Copy milliseconds" copy the value at the moment you click.
What date is 1704067200?
January 1, 2024, 00:00:00 UTC. In New York that is 7:00 PM on December 31, 2023. The 13-digit 1704067200000 is the same moment written in milliseconds.
What is the difference between 10-digit and 13-digit timestamps?
For present-day dates, 10 digits means seconds and 13 digits means milliseconds. The millisecond value is 1,000 times the seconds value for the same moment. 16 digits is microseconds and 19 digits is nanoseconds. Reading 10 digits as milliseconds gives January 1970, and reading 13 digits as seconds gives a date tens of thousands of years away, so check the unit first if a date looks wrong.
How do I convert a local date to a timestamp?
Enter the date and time and choose your time zone, and the seconds appear in the number field. For example, January 1, 2024, 00:00:00 in New York is 05:00 UTC, which is 1704085200 seconds. Leave the zone on "This device" to use your own clock's zone.
What is the Excel formula to convert Unix time to a date?
With seconds in A1, =A1/86400+DATE(1970,1,1) gives the UTC date. For New York standard time, subtract 5/24 at the end (4/24 in summer). For milliseconds, divide by 86400000 instead of 86400. Format the result cell as a date and time or you will only see a number.
What is the Year 2038 problem?
If seconds are stored in a signed 32-bit integer, the largest value is 2,147,483,647, which is January 19, 2038, 03:14:07 UTC (10:14:07 PM on January 18 in New York). The next second does not fit. Storing the value in a 64-bit integer avoids the problem.
Can a Unix timestamp be negative?
Yes. Any moment before 00:00:00 UTC on January 1, 1970 is negative. -1 is 23:59:59 UTC on December 31, 1969, and the signed 32-bit minimum, -2,147,483,648, is 20:45:52 UTC on December 13, 1901.
Does Unix time include leap seconds?
No. POSIX counts every day as exactly 86,400 seconds. UTC has had 27 leap seconds since 1972, but Unix time has no number for 23:59:60, so the value after 23:59:59 on December 31, 2016 (1483228799) is 1483228800, which is already 00:00:00 on January 1, 2017.
Why does daylight saving time change the result?
Because the offset from UTC is different in summer and winter. New York is UTC−5 in winter and UTC−4 in summer, so noon on July 1, 2026 is 1782921600, not the 1782925200 you would get with a fixed −5. The converter uses the offset in force on the date you enter.
Can I convert microseconds and nanoseconds too?
Yes. 16 digits is read as microseconds and 19 digits as nanoseconds, and both are calculated as exact integers. JavaScript's ordinary Number cannot hold integers above 2^53 exactly, so the last digits of a nanosecond value would change, but this converter uses BigInt arithmetic.