Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question
5  
I'm already stockpiling tear gas grenades and bottled water! :P –  Kevin Cantu Aug 19 '10 at 3:04
add comment

10 Answers 10

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.

share|improve this answer
    
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
add comment

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

share|improve this answer
    
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 6 '11 at 17:32
add comment

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 2010. 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.

share|improve this answer
    
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 7: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 7: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). –  Maciej Piechotka Aug 18 '10 at 19:31
add comment

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.

share|improve this answer
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). –  Maciej 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
1  
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 6 '11 at 19:52
add comment

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

share|improve this answer
add comment

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).

share|improve this answer
    
Except that this problem is caused by the UNIX time_t type being 32-bit. –  Yuhong Bao Jul 6 at 4:50
add comment
#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.

share|improve this answer
    
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. –  Maciej Piechotka Aug 18 '10 at 17:13
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
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 7:55
add comment

The Y2K problem was two charters representing the year instead of four.

Many system had no way to distinguish between 2000 from 1900 since they only stored the '00'.

Almost all system either now use 4 chars to store the year, or they use a library of some sort.

So lets all worry about the year 10000 (Y10K) instead. Except for the OS and Library writers...

share|improve this answer
    
Probably noone (well practically noone) is storing date is such format (i.e. DCD or string) now. Time are usually handling by objects or ints (so only display code would need to be updated). –  Maciej Piechotka Aug 18 '10 at 14:11
    
Yes, my point exactly. Y2K effectively killed the idea of representing dates as fixed length strings. –  Stephen Jazdzewski Aug 18 '10 at 14:14
    
@Stephen: Not in the COBOL world, but there are fortunately few COBOL implementations on Unix/Linux. –  David Thornley Aug 18 '10 at 15:01
    
@David: COBOL programs were the Y2K problem for the most part. Did Linux/Unix systems, from a users standpoint, ever have a Y2K issue? The simple answer to the original question is no. –  Stephen Jazdzewski Aug 18 '10 at 16:08
4  
The poster is not asking about the y2k problem; they're asking about the y2k38 problem, which is an entirely different beast. Check en.wikipedia.org/wiki/Y2K38 for a description. –  Kevin M Aug 18 '10 at 17:47
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.