The document discusses the potential "Y2K38 bug" that could cause issues for computers and software in 2038 due to timestamps being stored using 32-bit integers, which will reach their maximum value and roll over on January 19th, 2038. This will cause time values to incorrectly jump back to 1901. The solutions proposed include switching systems to 64-bit architectures, updating programs to handle 64-bit timestamps, and updating core time libraries. Overall, the conclusion is that there is no need to panic as there is still plenty of time to implement solutions and prepare for this issue.

1. Will the computer
world collapse in
2038?
1

2. Introduction
๏ Time is not a measurable
life-factor
๏ Compter Sciences engineers
enclosed time as Timestemp

3. The Timestamp
๏ Mechanism to store datetime
values as a standard time
format
๏ Number of elapsed seconds since
1/1/1970 00:00 UTC
๏ Coded on a 32-bit signed
integer (2^31 -1)

4. What’s the Y2K38
bug?
๏ Time limit: 01111111 11111111
11111111 11111111
๏ 2^31 – 1 = 2,147,483,647 seconds
๏ Limit will be reached on Tuesday
19th, January 2038 at 03:14:07 (UTC)
๏ Back to Friday 13th, December 1901,
20:45:52 (UTC)

5. Any solution?
๏ Switching all computers to
64-bit architecture
๏ Update programs to manage
64-bits timestamp format
๏ Update internal time_t core
library

6. Conclusion
๏ Don’t worry!
๏ 30 years to get prepared
and solutions already
exist
๏ No need to make a Y2K-like
ado!

7. Question 0001
Why timestamp creators
didn’t think about this
leak on time?

8. Question 0010
How much will this bug
cost?

9. Thanks!