The 2038 bug

My curiosity recently brought me to analyse what is the exact nature of the 2038 date problem.

Well as you all probably know, it comes from the limitation in the C standard library type 'time_t' which is usually defined as a 32 bits signed integer.

The time_t type is defined by the C standard to contain "the number of seconds elapsed since January 1, 1970, 00:00:00". The C documentation says it can contain dates up to January 18, 2038, 19:14:07.

But when I calculate the number of seconds a 32 bits signed integer can contain, I come to the number 2147483647, which is 24855 days, 3 hours, 14 minutes and 7 seconds. Adding this value to January 1, 1970, 00:00:00 gives the following date: January 19, 2038, 03:14:07

So how can you explain the difference between the C documentation date and the calculated date ?
Who is Participating?
Infinity08Connect With a Mentor Commented:
>> January 19, 2038, 03:14:07

That's the highest UTC date/time that can be represented by a signed 32bit time_t.

>> January 18, 2038, 19:14:07

That would thus be the highest date/time in UTC-8.
Are you sure you included all leap years correctly in your calculation?
>> The C documentation says it can contain dates up to January 18, 2038, 19:14:07.

What timezone was that documentation for ?
stsanzAuthor Commented:
Well I found all the explanations here :

Thanks for your comments
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.