• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 306
  • 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
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.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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