27

What is the likelihood of the Year 2038 issue being very problematic?

Gilles 'SO- stop being evil'
  • 829,060
8128
  • 405

9 Answers9

17

I have encountered this problem in an embedded Linux system that needed to handle dates past 2038 in some long-term cryptographic certificates, so I'd say the likehood of this depends on your application domain.

While most systems should be ready well before 2038, if you find yourself today calculating dates far into the future, you may have a problem.

Alex B
  • 4,478
  • Good one! I did not think of that example! What does the PKI standard use as a time syntax inside certificates? I have never looked! – geoffc Aug 18 '10 at 14:55
  • @geoffc, Actually it was a proprietary format and had its internal date/time structures, which themselves were big enough to fit dates past 2038, but it used GLIBC functions for date/time conversion. If I recall correctly, mktime call was silently failing. – Alex B Aug 18 '10 at 23:36
13

I think this is going to be a significant problem, much more pernicious than the Y2K issues of 1999/2000 because the affected code is generally lower-level (it's CTIME) and so it's harder to spot places where time is being stored that way.

To complicate matters further, the fact that Y2K was perceived to be a damp squib will make it harder to draw attention to the problem in the runup to the event.

Cultural references:

Cory Doctorow was trying out a new model for short story commisioning / publishing under open licenses, and I suggested a 2038 theme o one of them, which he did brilliantly in Epoch: http://craphound.com/?p=2337

Mark Shuttleworth
  • 411
  • Speaking as somebody who was working on the issue at the time, Y2K fizzled because of a lot of work and planning beforehand. The damp squib perception was reinforced by all the exaggerated doomsaying in the media. I expect there to be a lot of planning and work done starting in 2035 or so, but if we're lucky we'll miss the media blitz. – David Thornley Aug 18 '10 at 15:06
  • Cheers for the link Mark. – boehj May 06 '11 at 17:32
9

A few years ago, there were reports of problems already, in areas like mortgage programs doing calculations on 30-year loans: 2008 + 30 = 2038.

Warren Young
  • 72,032
8

This is my opinion, but this problem is due to a 32 bit counter problem, today most os are updated to handle time on 64 bit (at least on 64 bit computers), so I guess that all OS and software will be ready a long time before 2038, let's say 2020. So you might only have problems if in 2038 you will still be running software from 2020.
It likely not be a problem in almost all case. I hope.

radius
  • 367
  • I tried Ubuntu 32 bit version and it showed 2038 problems but running Ubuntu 64 bit version showed no sign of 2038 problem. I haven't tried any other Unixes. – Jimmy Hedman Aug 18 '10 at 07:43
  • Yes on most 32 bit version you will see the problem but not on 64 bit version. You can expect to have no longer any 32 bit OS in 2038. – radius Aug 18 '10 at 07:58
  • 2
    This is a ridiculous assumption. We still use 16(and even 8 bit) microprocessors in todays world, what is to say 32 bit microprocessors will magically disappear in the future? It is fair to say this will not impact the average user, but in edge cases it could continue to be a problem. – Eli Frey Aug 18 '10 at 16:30
  • Well - the 16-bit and 8-bit computers can 1. move date 0 (from 1970-01-01 to for example 2010-01-01) - however it would break certain API/ABI conventions 2. extend the timer field (which may in certain cases break 'only' ABI). – Maja Piechotka Aug 18 '10 at 19:31
8

A 64 bit OS is ultimately irrelevant to the 2037 problem. (CTIME runs out closer to 2037 than 2038).

The question is not the bit depth of the OS, rather how does the OS store time. Or how does the database column choose to store time. Or how does this directory services time syntax attribute store time at the back end.

This is a much bigger problem than people think, since it is so endemic and common to have used 32 bit time counters.

Each instance that stores time needs to be revisited, and all API's updated, and all tools that use it updated as well.

Abstraction layers that let you set time via a human readable time format, instead of the raw data written out make it easier, but that is only one case.

I suspect this is going to be a much bigger deal than most people think.

geoffc
  • 668
  • 4
  • 13
  • 18
  • 1
    The biggest problem I see are file formats and filesystens, However date range for ext4 is 2514, vfat is 2107. Problem is with reiserfs (2038). – Maja Piechotka Aug 18 '10 at 14:08
  • ReiserFS has other issues still as well. I still think there are many more hidden places than people think of that store time in CTIME. It is a darn easy and useful time format. Of course, unsigned CTIME does not have the 2037 problem. I think that is the 2107 timestamp case. – geoffc Aug 18 '10 at 14:54
  • 2
    You're thinking of Apple HFS. FAT doesn't use time_t at all. It stores year, month and day as fields in one 16-bit value: 5 bits for day, 4 for month, leaving 7 for year. 2107 is 1980 (year zero in FAT land) + 2^7-1. For more fun, FAT stores time of day the same way in another 16-bit value, but if you do the math, you find that you need 17 bits to store time of day this way. FAT gets around this by dropping one bit of resolution for seconds; FAT can't distinguish changes less than 2 seconds apart. Ah, Microsoft, what a boring world this would be without your needless incompatibilities! – Warren Young Jun 06 '11 at 19:52
1

32 bit systems still running by then will be a problem.

user55149
  • 11
  • 2
    Could you elaborate on that, to make it more clear what exactly becomes the problem, and how to react to that? – Anthon Dec 22 '13 at 07:55
  • The issue is with the 32 bit integer that is used for calculating time. Time is measured in number of seconds elapsed since Jan 01 1970. For example after one day this counter will be at 86400. So in 2038 this value will overflow as it will hold a value that is greater than the number that can be held in an unsigned 32 bit integer. A 64 bit system using 64 bits for the timestamp will not have this issue as it will be able to work till 15:30:08 on Sunday, 4 December 292,277,026,596 (292 billion years) – Rahul Kadukar Apr 26 '16 at 14:14
1

Not such a big deal.

During the first Y2K blitz, in which software and hardware vendors were required to certify their products as "Y2K compliant" in order to be sold (I remember network cables on PC Connection being certified Y2K compliant) a lot of companies did detailed audits of everything, by setting clocks in the future and testing.

At the time, since the cost of testing was so high, they almost always tested with several dates, such as 1/1/99 (some developers may have used 99 as a sentinal), 12/31/99, 1/1/00, the leapness of 2000, 1/19/38, and many others. See here for a tedious list.

Thus I believe that any important software that was around in 1999 will probably not have 2038 bugs, but new software written since then by ignorant programmers might. After the whole Y2K debacle programmers generally became much more aware of date encoding issues so it's unlikely to be as big an impact as Y2K was (which, in itself, was something of an anticlimax).

Joel Spolsky
  • 119
0
#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

it should be 1 instead of 9 but ctime does not handle larger date:

8 - Sun Jun 13 07:26:08 1141709097

My system (64 bit of course) time can run even 1 million years more. The solution is to update the systems to 64 bits.

The catch is that the programs may not handle it. Especially old, propertary and not maintained. Devs are used to following facts:

  • int's are 32 bits (in fact they are preserved as 32 bits on 64-bit systems among others because it was assumed they are 32 bit always)
  • Most types (such as time_t) can safely be casted on int

In popular FLOSS software both things will probably not get through the 'many eyes' review. On less popular and propertary it will largly depend on author.

I guess on free *nix world the 2038 will get 'unnoticed' while I do expect problems on "propertary" platforms (i.e. those with large number of propertary software) - especially if some of the crutial part will not be maintained.

Maja Piechotka
  • 16,676
  • It is not the 'system' or 'OS'. Most any previous 32 bit OS (heck even 16 bit OS's) could do 64 bit math. The 64 bit depth at the OS level is basically a reference to memory model, not ability to do math. And time is all about math. – geoffc Aug 18 '10 at 14:56
  • Yes and no. It is true that 32 bit and 64 bit OS can perform 64 bit arithmetic (you can emulate any arithmetic). However time_t (or equivalent) on 32 bit OS happens to have 32 bits while time_t(or equivalent) on 64 bit OS happens to have 64 bits. I thought it was sufficiently clear even if with certain simplification. – Maja Piechotka Aug 18 '10 at 17:13
0

If it's anything like Y2K, some people have already been affected and are changing software, but most developers will ignore it until sometime in the 2030s, probably 2035 or so, at which point there will be a lot of work done, and anybody old enough to know K&R C and not yet too senile will suddenly be able to contract out for a lot of money. The actual transition will show a lot of things not yet done, probably none all that important.

David Thornley
  • 363