Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 305
  • Last Modified:

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 ?
  • 2
1 Solution
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 ?
>> 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.
stsanzAuthor Commented:
Well I found all the explanations here :

Thanks for your comments

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now