
Year 2038 problem - areski
http://en.wikipedia.org/wiki/Year_2038_problem
======
apaprocki
Just wanted to point out that this has affected software revolving around
finance for some time now. Historical data goes back into the 1800s and there
are bonds with very, very long horizons (100-year or approaching it). The last
time I checked on Bloomberg I believe the latest maturity date I could find in
the system was sometime in 2089. I think the industries that have had to deal
with this already will not be very affected by 2038.

edit: Link to C++ N3344 paper we wrote, describing how we represent dates
(times/datetimes are similar): [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2012/n334...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf)

edit2: Anyone interested in examples -- on the early side:

    
    
        ISIN GB0000436070, UK Gilt, issued 1853, perpetual annuity
    

On the future side, things have changed since I last looked. Example bonds
with the latest dates I can find are:

    
    
        ISIN XS0560190901, Dong Energy A/S, callable 06/01/3010
        ISIN US786581AA66, HSBC Holdings Luxembourg SA, callable 10/15/2997

~~~
kevindication
Right, but just because you have a data type that can handle a date that far
in the future does not imply that you have fixed your OS and supporting
software to be able to handle the day when the system time rolls over.

~~~
apaprocki
Yes, it really just depends how much your software stack depends on the OS and
higher level OS-related services. If your software is not coupled with other
points of failure in OS user-land, then you really only need a single entry
point to get network-sync'd 64-bit time_t and then everything else in the
stack can be built around vocabulary data types such as these. These are the
types that are transmitted in protocols, serialized to files, etc.

------
Ovid
Actually, a friend of mine has written a fix for it
(<https://github.com/schwern/y2038>) in C. Just use the new functions and
you're probably good. It's under an MIT license, so have fun with it.

Me? I'm waiting for the idiots who claim it's a worldwide geek conspiracy _à
la_ Y2K. Here's a haiku (senryu) I wrote for that:

    
    
        Is Y2K real?
        The problem's being solved by
        Men who can't find dates.

~~~
0x0
This won't help you if you need to interface with existing files or
protocols...

~~~
btilly
Change all unsigned ints that store time to signed.

In another 68 years or so, change them all back to unsigned.

:-)

~~~
GhotiFish
While I agree this works, It's also a bit unnerving to me that 68 years later
we're still using a protocol that's using a representation of time that rolls
over every 126 years.

------
Graham24
The system I'm working on counts time as an unsigned 32-bit int starting in
1900 (don't ask). I think we fail in 2036 and that's a mere 23 years time.

It does really annoy me when idiots talk about the Y2K problem as being
nothing at all and just a hyped-up non-event.

I for one, worked on fixes for Y2K and it all went seamlessly because we
(collectivly) worked hard and got it right and no reactors/missles blew up and
the banks did not fail.

~~~
glhaynes
Same thing whenever those "useless" organizations like the World Health
Organization monitor/quarantine people and animals showing new strains of the
flu. Afterward, I inevitably hear a "well, that sure was a dud... all that
expense and trouble over a flu that didn't turn out to be a big deal. They're
just trying to scare us to justify their jobs." Infuriating.

------
ryanthejuggler
"Other automotive safety systems include anti-lock braking system (ABS),
electronic stability control (ESC/ESP), traction control (TCS) and automatic
four-wheel drive."

So anti-lock brakes are going to stop working after the wraparound? Seems to
me that either (a) they're relying on code that they shouldn't--why should ABS
depend on date and time? or (b) the article is just giving examples of
embedded systems that _could_ fail.

If case (a) is true, I imagine (or would like to think) that they're just
using the timestamp to perform some simple physics computations of how to
control the brakes. If this is the case, they could just use the uptime of the
processor instead. Then they would only bump into this issue if the car ran
nonstop for 60+ years, which is a reasonable thing to assume will not happen.

If case (b) is true, then the article needs a bit more research into examples
of systems that actually rely on datetime.

~~~
derekp7
Seen the same thing back with Y2K -- all kinds of scare mongering using
countless embedded systems as examples -- but not one of those examples has an
interface where you can set the current date/time. As long as it isn't
blinking "12:00" (or more precisely "Jan 1, 1970 00:00 UTC") when you first
turn it on, you don't have to worry about it.

Sure you have to set the time on your microwave, but none of the ones I've had
displayed a calendar date.

~~~
jrabone
True. There are also some ingenious "solutions" out there - like my DECT phone
for example. The interface takes time and date (with NO year field) in one
menu, and day-of-week in a different menu on the base station... (if it's got
a look-up table somewhere and is calculating epoch-second timestamps from this
I will ritually burn it.)

------
majke
You can use `libfaketime` to test your software:

* <https://github.com/wolfcw/libfaketime>

Shameless plug: my project `fluxcapacitor` may also be useful for testing:

* <https://github.com/majek/fluxcapacitor>

~~~
ccozan
I can only recommend libfaketime. It great to test all kind of software, which
either depends on some time of day or, alternatively ( but not recommended! )
to circumvent some other software with a built in license expire time.

------
ck2
I like to make sure future programmers have work to get paid for so I always
make sure my databases use 32-bit integers for time :-)

Seriously though, in 20-25 years I think we cannot even fathom how fast and
parallel databases will be, an ALTER will probably take a few seconds on a
billion row table.

~~~
Ovid
As someone who had some fun (er, not) during the Y2K debacle, I can promise
you it's a lot more than just altering databases or patching a few bits of
code. Sometimes the code is impossible to understand. For example, one program
named all the variables after types of alcohol and had lines like:

    
    
        compute martini equals gin plus vermouth.
    

(Yeah, I used to hack COBOL, too).

Other times there would be absolutely critical systems which were developed,
but were tucked away on an unknown server and we'd find out about them at the
last minute and panic trying to figure out if they would work correctly.

And if you get into languages who have severe bondage and discipline on
datatypes, finding out that the subtly altered data that works in one system
is blowing up another one just isn't fun.

What's worse: sometimes the logic just _assumes_ that dates can't be past a
certain time. Ooh, let's set the date to maxint of this data type and use that
as the cutoff in our code. This code won't exist then, right? Naturally, the
tests hard-code a datetime in them and it won't show up even when clocks are
deliberately set forward to test the code. Of course, I've hacked on code that
was written before I was born, so the whole "this code won't exist then"
actually means "I won't be working here then".

~~~
MartinCron
_compute martini equals gin plus vermouth_

That's the most terrible code I've ever read. There's no units, it doesn't
specify the ratio of gin to vermouth. That's not a martini, that's a mess.

~~~
Ovid
I just kept recompiling it until it tasted right.

------
api
Most 64-bit systems have a 64-bit time_t, so this won't affect them. Some
32-bit systems have also shifted to a 64-bit time_t. But it will be an issue
that'll require a lot of recompiling and patching of ancient legacy stuff.

~~~
vidarh
Even on 64 bit platforms with 64 bit time_t you are assuming that time is
always stored in time_t, and never stored in or exchanged with systems that
still use 32 bit time values. That's by no means a safe assumption.

~~~
r00fus
So there's the rub.

It's all the integration/glue code that's the problem.

The dark matter of the programming world.

------
pilif
I think a much bigger problem than old software on 32 bit machines is the fact
that some (binary) protocols use 32 bit integers to encode dates. That means
that even when hardware and OSes get updated and even if servers or clients
are maintained, stuff will still go wrong when the protocols are wrong.

So keeping up to date software might not be enough. We'll also have to
pressure our peers to update and to adapt new protocol versions (that might
have other changes in addition to just the widening of the timestamps)

~~~
stephengillie
<http://xkcd.com/607/>

------
jrabone
You leave that bug alone, that's my retirement policy that is.

~~~
mkopinsky
Your "pull me out of retirement to fix mission critical bugs" policy, rather.

~~~
angersock
That's funny, where I'm from the policy is called "jQuery".

~~~
jrabone
Every generation of coders has its retirement policy. Just think where we'd be
if every large company was agile, responsive, and kept their code up to date.
We cannot afford to let the big banks, governments and healthcare companies
keep up!

------
elliottcarlson
For PHP developers - date(), mktime() and strtotime() (as well as other
functions) use 32bit signed integers for storing the date representation
(except in some instances of a 64bit version of PHP on a 64bit OS), which is
not y2k38 safe. It is preferred to use the DateTime class available in 5.2 and
above which stores the date in a 64bit signed integer. There are other reasons
to use the DateTime class as well - and it should generally be best practice
to move away from date(), mktime(), strtotime() and other similiar
functionality.

------
markhelo
I own 2038K.com, if anyone has interesting ideas on what to do with it besides
making money from ADS, let me know. I bought it as a retirement hedge with the
evil plan to drum up doomsday scenarios to drive traffic. Wait, I am sure the
media will take care of that for me when the date approaches.

~~~
njharman
Countdown Timer. Should underflow at the last second, of course.

------
404error
No need to worry about this. John Titor will fix this problem.

<http://en.wikipedia.org/wiki/John_Titor>

~~~
johansch
Three options:

1) Someone gone insane from too much exposure to IBM mainframes (seems quite
likely)

2) A great performance artist - making us all think

3) A real time traveller

~~~
404error
According to Titor though what ever he did in our time would not directly
affect his time. He traveled through time to a parallel universe(our universe)
where things are pretty similar to his time with some differences.

According to him the farther back or forward in time he goes the more things
change.

So, with that said, we might still be screwed. But maybe we can find an IBM
5100 and solve this problem.

------
cleaver
I tried to register a Year 2038 related domain in the late 90's. Anything good
was taken.

I assume the more interesting aspect of Y2038 will be the societal... Will we
all be stocking our bunkers with 5 gallon pails of dried pinto beans and
arming our personal attack drones?

I'd like to think we'll be a bit wiser, but somehow doubt it. Software is full
of date related bugs and fails all the time. The world didn't end before,
during, or after Y2K. I don't think it's ending in 2038.

~~~
umsm
I dont think you looked hard enough. :) The late 90s to about 2004 most good
domains were being registered. Now we have to settle for foreign TLDs.

~~~
nwh
I wouldn't worry too much. Soon we'll have .horse and .melbourne, all our TLD
problems will be behind us.

~~~
cleaver
I'll be snapping up 2038.horse for sure. Once all our computer controlled
hybrid vehicles stop functioning, I predict a booming market for horses.

------
pserwylo
"REPENT FOR THE END OF THE UNIX EPOCH IS NIGH" [0]

... was a very entertaining and interesting talk from linux.conf.au 2013. The
first ten or so minutes is amazing theater and quite hilarious (at least it
was when I saw it live), and the remaining talk is also very informative.

It deals with quite a clever way to re-use the existing timezone databases
that are designed to work with 32bit dates, such that they are usable with
64bit dates. This is important, because it is already an extremely difficult
task to keep the original 32bit timezone databases up to date (what with all
of the political decisions to change daylight savings - at a few months
notice).

The talk is from the perspective of a perl developer, but the discussion is
for anyone who is interested in solving the Year 2038 Problem in their
language of choice.

[0] <http://www.youtube.com/watch?v=eQFZ_MPTVpc>

or 91mb mp4 download:

[http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR...](http://mirror.linux.org.au/linux.conf.au/2013/mp4/REPENT_FOR_THE_END_OF_THE_UNIX_EPOCH_IS_NIGH.mp4)

------
lucb1e
Unsigned integers will get you going till the year 2106, that could be an easy
hotfix if you don't have to store datetimes before 1970.

Using 64-bit integers is overkill, they will work till the year 584bln[1] and
it's twice as much data for every timestamp. Adding one byte (5-byte integers)
is uncommon, but that supports the year 36000 already, so it would be more
than enough.

[1] In full, till the year 584 942 419 325.

~~~
PavlovsCat
I don't mind doubling the size that much, but why not have milliseconds
instead of seconds? 500+ billion years is just silly.. 500 million years ought
to be enough for any civilization.

~~~
ygra
Windows uses 100-ns intervals since 1601 (start of the current 400-year cycle
of the Gregorian calendar at the point where NT was designed) which offers
good accuracy and should last for the foreseeable future.

------
codeulike
I hope humans are still around to deal with the eventual Y10K problem.

------
TorKlingberg
We should take the time to appreciate the people who choose to design text
based protocols like SMTP and HTTP. They may be a little inefficient, but at
least they don't suffer from arbitrary numerical limits like this.

~~~
astrodust
Using text was largely a way to make implementation easier, more human
readable, and also conveniently avoid endian issues.

The arbitrary numerical limits are usually in the implementation, as many a
buffer overflow bug as demonstrated.

~~~
anonymouz
But the point is that the implementations can be fixed, one by one, without
breaking the protocol.

------
DanielShir
This bug is my retirement fund :) Just like those COBOL guys back in 2000.

------
smackfu
There's also another Year 20XX problem lurking out there.

A lot of mainframe code that was fixed for Year 2000 had two-digit years in
the data, that was converted to a four-digit year by adding 1900. The "fix"
for a lot of that was to say if it was less than 70 (or whatever cutoff
handled all the dates for the application), add 2000, otherwise add 1900. 72
=> 1972, 00 => 2000, 13 => 2013\. This fails in 2070, with 2070 being reported
as 1970 again.

That same software is untouched 13 years later... I don't have hopes for it
being updated soon.

------
radimm
I remember times of y2k and thinking both how 2038 is far away and that none
of the system we use will be there :) 13 years later (1/3 of the time) I'm not
longer that sure...

------
lambersley
When Y2K happened, I was just entering the workforce. I missed the opportunity
to capitalize on the madness. This time, this time I will profit

------
devinfoley
I ran into this issue recently.

You can't create an authenticated S3 URL without an expiration date, and it
doesn't accept an expiration date after 2038.

------
jtwigg
watch out for the Year 292,277,026,596 problem

~~~
astangl
I put a (semi tongue-in-cheek) comment in some billing system code I wrote 8
years or so ago, pointing out a date overflow problem, something like
Y292277026596 (can't remember the exact year now, but the comment was
accurate). Comment went on to say that if the system was still in use at that
time, then I would fix the problem.

I expected to be called out for this comment some day, but never have -- makes
me wonder how often people read through code.

------
jlove
This finally made me get around to posting my 2038 countdown clock.

<http://diskclock.com/2013/05/unix-disk/>

------
sopooneo
The Y2K issue was at least explainable to non-techs. Storing two digits is
ambiguous. Simple enough. This one, though, no one is going to understand.

------
normalocity
3:14 - Pi time in Jan. 2038.

Get a Pi(e) and enjoy eating it as the world collapses...or when the world is
just fine you will have just enjoyed a delicious pie.

------
Eva_Peron
does anyone have a start-up dedicated to solving this issue? something like an
Initech for the 2038 bug? If not someone should.

------
emeidi
I was there when Y2k happened! Alas, nothing happened except I was suffering
from a huge hangover the very next morning.

~~~
mark-r
I ended up with a gas station receipt that said "1/1/100". That was the extent
of it.

------
human_error
This has been fixed couple of years ago in mortgage systems.

------
colkassad
Just curious, was anyone talking about Y2K back in 1975?

------
guard-of-terra
Java won't be affected because it sees timestamp as a 64-bit signed number of
milliseconds since epoch.

It's precise enough for logging now and also timeproof.

This is fortunate because there are huge legacy java codebases. However,
problems may still arise where java talks to other things (databases,
input/output).

------
yoster
Rerun of Y2K...

