Unix time passes a round hundred million roughly every three years. The three most recent milestones were 1500000000 in July 2017, 1600000000 in September 2020 and 1700000000 in November 2023.
This article lists the exact dates for each milestone, shows how they appear in different time zones, and explains why round-number timestamps are useful when you debug or test time-related code.
Quick reference
| Unix timestamp | ISO 8601 (UTC) | Day of week (UTC) |
|---|---|---|
1500000000 |
2017-07-14T02:40:00Z |
Friday |
1600000000 |
2020-09-13T12:26:40Z |
Sunday |
1700000000 |
2023-11-14T22:13:20Z |
Tuesday |
Open any of them in the converter: 1500000000, 1600000000, 1700000000.
Unix timestamp 1500000000 {#1500000000}
Friday, 14 July 2017, 02:40:00 UTC. In France this was Bastille Day, though only just: 04:40 in the morning in Paris. Across North America it was still Thursday evening.
| Location | Local date and time | Offset |
|---|---|---|
| Los Angeles | 2017-07-13 19:40:00 | UTC−07:00 |
| New York | 2017-07-13 22:40:00 | UTC−04:00 |
| London | 2017-07-14 03:40:00 | UTC+01:00 |
| Berlin | 2017-07-14 04:40:00 | UTC+02:00 |
| Tokyo | 2017-07-14 11:40:00 | UTC+09:00 |
| Sydney | 2017-07-14 12:40:00 | UTC+10:00 |
In milliseconds the same instant is 1500000000000. JavaScript developers may recognise the pattern: from this moment until September 2020, Date.now() returned values starting with 15.
Unix timestamp 1600000000 {#1600000000}
Sunday, 13 September 2020, 12:26:40 UTC. Because it happened around midday UTC, this milestone fell on 13 September in nearly every populated time zone, from Los Angeles to Sydney.
| Location | Local date and time | Offset |
|---|---|---|
| Los Angeles | 2020-09-13 05:26:40 | UTC−07:00 |
| New York | 2020-09-13 08:26:40 | UTC−04:00 |
| London | 2020-09-13 13:26:40 | UTC+01:00 |
| Berlin | 2020-09-13 14:26:40 | UTC+02:00 |
| Tokyo | 2020-09-13 21:26:40 | UTC+09:00 |
| Sydney | 2020-09-13 22:26:40 | UTC+10:00 |
Unix timestamp 1700000000 {#1700000000}
Tuesday, 14 November 2023, 22:13:20 UTC. Late evening in UTC means the next morning in Asia and Australia, so this milestone happened on 14 November in Europe and the Americas and on 15 November further east.
| Location | Local date and time | Offset |
|---|---|---|
| Los Angeles | 2023-11-14 14:13:20 | UTC−08:00 |
| New York | 2023-11-14 17:13:20 | UTC−05:00 |
| London | 2023-11-14 22:13:20 | UTC+00:00 |
| Berlin | 2023-11-14 23:13:20 | UTC+01:00 |
| Tokyo | 2023-11-15 07:13:20 | UTC+09:00 |
| Sydney | 2023-11-15 09:13:20 | UTC+11:00 |
Notice that the offsets changed compared to the earlier tables. By November, New York and London had left daylight saving time, while Sydney had entered it. The same city can have a different UTC offset at different milestones, which is exactly why fixed offsets should never be hard-coded.
The rhythm of round numbers

One hundred million seconds is exactly 1,157 days, 9 hours, 46 minutes and 40 seconds. Because that interval is not a whole number of days, each milestone happens 9 h 46 min 40 s later in the day than the previous one:
| Unix timestamp | Date (UTC) | Time (UTC) |
|---|---|---|
1000000000 |
2001-09-09 | 01:46:40 |
1100000000 |
2004-11-09 | 11:33:20 |
1200000000 |
2008-01-10 | 21:20:00 |
1300000000 |
2011-03-13 | 07:06:40 |
1400000000 |
2014-05-13 | 16:53:20 |
1500000000 |
2017-07-14 | 02:40:00 |
1600000000 |
2020-09-13 | 12:26:40 |
1700000000 |
2023-11-14 | 22:13:20 |
1800000000 |
2027-01-15 | 08:00:00 |
1900000000 |
2030-03-17 | 17:46:40 |
2000000000 |
2033-05-18 | 03:33:20 |
2100000000 |
2036-07-18 | 13:20:00 |
Every third milestone lands on a whole minute, because 300,000,000 seconds is exactly 3,472 days, 5 hours and 20 minutes: 1200000000 at 21:20:00, 1500000000 at 02:40:00, 1800000000 at 08:00:00 and 2100000000 at 13:20:00. 1800000000 is the only one that falls exactly on the hour, which makes it a neat value for readable tests.
The next step after 2100000000 would be 2200000000, but that is already beyond the signed 32-bit limit at 2147483647. Systems that still store time in a 32-bit signed integer cannot represent it. The next billion, 2000000000, is covered separately.
Why round numbers help when debugging
Round timestamps are easy to spot in logs, fixtures and database rows. A few practical uses:
- Readable fixtures.
1700000000is easier to read in a test than1699999783, and anyone can verify it quickly. - Recognising units. If a value looks like
1700000000000, you instantly know it is milliseconds, and1700000000000000is microseconds. The main guide lists all precision levels. - Rough dating. Knowing that 1.5 billion is mid-2017 and 1.7 billion is late 2023 lets you estimate a timestamp's age at a glance. A value starting with
17in seconds is from late 2023 to early 2027. - Scheduling tests. Jobs that must run "at a specific instant" can be tested against a round future value. Tools such as the Cron Expression Generator help when the same job also needs a recurring schedule.
Converting the milestones in code
JavaScript
for (const ts of [1500000000, 1600000000, 1700000000]) {
console.log(ts, new Date(ts * 1000).toISOString())
}
// 1500000000 2017-07-14T02:40:00.000Z
// 1600000000 2020-09-13T12:26:40.000Z
// 1700000000 2023-11-14T22:13:20.000Z
Python
from datetime import datetime, timezone
for ts in (1_500_000_000, 1_600_000_000, 1_700_000_000):
print(ts, datetime.fromtimestamp(ts, tz=timezone.utc).isoformat())
Shell
for ts in 1500000000 1600000000 1700000000; do date -u -d "@$ts"; done # GNU/Linux
Summary
Unix time crossed 1500000000 on 2017-07-14, 1600000000 on 2020-09-13 and 1700000000 on 2023-11-14, all in UTC. The next milestone, 1800000000, arrives on 15 January 2027 at 08:00:00 UTC. Milestones are spaced 1,157 days and 9 h 46 min 40 s apart, and each one falls on different local dates depending on the time zone.
Paste any of these values into the Unix Timestamp Converter to see them in your own time zone, or go back to Unix Timestamps Explained for the fundamentals.