<p>The 32-bit <em>signed</em> integer timestamp runs out in 2038. But Bitcoin uses a 32-bit <em>unsigned</em> integer for the timestamp. That runs out it the year 2106. We'll have to find a solution by then, not by 2038. Since that is still a long ways off, there is no plan for changing the timestamps yet.</p>

<p>Whatever happens would not affect existing blocks. The same thing would happen as with any other fork: blocks prior to the activation block are verified with the old rules, and blocks following activation are verified with the new ones. So old blocks would use the current timestamp stuff and new ones would use whatever new scheme is created.</p>

CC BY-SA 4.0
2018-09-13T19:42:57.593Z
In principle, nothing has to be changed in the protocol, since AFAIK all that's ever relevant is the difference between timestamps of blocks with 2016 or fewer blocks in between.  If the code does its arithmetic correctly, everything would be fine unless the timestamps wrap around *twice* within that span.  If it takes 136 years to generate 2016 blocks, we have bigger problems.
Nate Eldredge
CC BY-SA 4.0
2018-09-13T19:06:07.673Z
2018-12-24T15:13:18.503Z
2018-12-24T15:13:18.503Z
Ava Chow
<p>Is there a plan in place for when the inevitable 32-bit overflow of Unix timestamps occurs?</p>

<p>How much will this impact existing blocks that are timestamped with Unix Epoch times?</p>

CC BY-SA 4.0
2018-09-13T19:46:03.690Z
The OpenBSD guys have solved this topic already: "From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC."
pebwindkraft
<blockchain><timestamp>
January 19th, 2038: RIP Unix Timestamps
apt-getschwifty
# January 19th, 2038: RIP Unix Timestamps

(Asked by: username_0 on 2018-09-13)

Is there a plan in place for when the inevitable 32-bit overflow of Unix timestamps occurs?

How much will this impact existing blocks that are timestamped with Unix Epoch times?

**Tags:** blockchain, timestamp

> **Comments:**
> **username_1**: The OpenBSD guys have solved this topic already: "From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC."  

---

## 1 answers

### Answer by username_2 on 2018-09-13. Score: 15 | Accepted answer

The 32-bit *signed* integer timestamp runs out in 2038. But Bitcoin uses a 32-bit *unsigned* integer for the timestamp. That runs out it the year 2106. We'll have to find a solution by then, not by 2038. Since that is still a long ways off, there is no plan for changing the timestamps yet.

Whatever happens would not affect existing blocks. The same thing would happen as with any other fork: blocks prior to the activation block are verified with the old rules, and blocks following activation are verified with the new ones. So old blocks would use the current timestamp stuff and new ones would use whatever new scheme is created.

> **Comments:**
> **username_3**: In principle, nothing has to be changed in the protocol, since AFAIK all that's ever relevant is the difference between timestamps of blocks with 2016 or fewer blocks in between.  If the code does its arithmetic correctly, everything would be fine unless the timestamps wrap around *twice* within that span.  If it takes 136 years to generate 2016 blocks, we have bigger problems.  

---

