
2038: Only 21 years away - corbet
https://lwn.net/SubscriberLink/717076/4c3593aa4cad8e66/
======
archgrove
This is (serious) a part of my retirement planning. I'll be mid-50s when this
hits, and have enough low level system knowledge to be dangerous. In about 15
years, I'll start spinning up my epochalypse consultancy, and I'm expecting a
reasonable return on investment in verifying systems as 2038 compliant.

~~~
DannyB2
My retirement planning is to work on the Y10K problem. When the year 9997
comes along, everyone is going to start worrying about the rollover to five
digit years. In about the year 9995 I will start seriously brushing up on my
COBOL.

~~~
narrator
Yes, I know some of us will never retire. 8000 years in the future career
planning is an interesting thing to think of though. 8000 years ago the only
thing that was going on was some neolithic agriculture. Domestication of the
Jungle Fowl (modern day chicken) in India and the beginning of irrigated
agriculture in Sumeria were probably the biggest news items of that
millennium. I guess someone from 8000 years ago could have said he'd be
raising chickens or doing irrigated agriculture in 8000 years and wouldn't
have been wrong had he lived that long. Makes me think of F.H King's book
"Farmers of Forty Centuries" about how Chinese agriculture has been farming
the same fields without artificial fertilizer for 4000 years.

~~~
contingencies
There was almost certainly some forms of relatively advanced seafaring 8000
years ago possibly including skin boats, sails and paddles, ropes, sealants
and astronomy. Also, fairly sophisticated metallurgy was widespread with at
least silver/iron/gold, possibly bronze. Writing was known to some cultures.
Horses, camels and water buffalo were likely all domesticated. Use of
drying/smoking for preservation and curing of meat. Yogurt may have been known
in some areas. Advanced pottery. Probably nontrivial herbalist / medicinal /
architectural / construction knowledge. Plus of course trapping, fishing,
textiles, stonework, etc.

~~~
valuearb
I can believe seafaring, astronomy, and metallurgy. But yogurt? Now you're
just pulling my chain.

~~~
clock_tower
I don't know how much you know about yogurt, so I apologize in advance if this
sounds condescending; but yogurt has been eaten since at least the 5000s BC,
and is easy to produce, probably even by accident. It's obtained by controlled
souring of unpasteurized milk; clabber, which is almost too sour to be edible
but is safe to eat if you can stand the taste, comes from spontaneous souring.

Fernand Braudel (in _The Structures of Everyday Life_ ) talks of how it was
the staple food of the poor in Turkey, and I think in Persia. US commercial
yogurt is weak and sugary; the Eastern variety is much more lifelike.

------
antirez
Using a 64 bit timestamp will only move the problem 292 million years forward,
so probably the best solution is to use a variable length field.

~~~
swalsh
Think about how much entropy will build up in systems over 292 million years.
Systems thousands of years old will be underneath newer systems hundreds of
years old.

The AI's will be scrambling to fix the problem.

~~~
zem
the scenario from "accelerando" is more plausible, where an AI rebuilt itself
from scratch to eliminate a thompson "trusting trust" hack.

~~~
Nition
Man, the plot summary of Accelerando sounded so good but I couldn't get past
the _writing_. That dense name dropping of random tech terms was a bit much in
particular.

~~~
zem
i found the writing very fun to read, but it's definitely a matter of taste.

------
Taniwha
This is not a problem for 20 years from now, I've already had to find and fix
2038 bugs ... there was an openssl bug (now fixed) in which cert beginning and
ending date math was done in 32-bits ... certs with an end date from a little
after 2038 would fail when compared with the current time.

Fortunately for me there was already a fixed OpenSSL already available once
I'd found the bug in it.

------
gbrown_
> statx() will serve as the year-2038-capable version of the stat() family of
> calls

Does this seem horrible to anyone else? Why not fix stat()? Does this syscall
have to be so highly preserved even when it will be broken?

One of the advantages of the OpenBSD approach of being able to make intrusive
changes saw their time_t made 64-bit in the 5.5 release in 2014.

[https://www.openbsd.org/55.html](https://www.openbsd.org/55.html)

Admittedly this is much harder for Linux as they can't make the change an
verify in a single place due to the separation of kernel and userland/ the
fact Linux has many distros.

~~~
Aissen
In Linux kernel land, the golden rule is to never break the userspace ABI.
Yes, it might happen, but it's _never_ intentional, unless there's no other
choice (glaring security issue for instance).

~~~
gbrown_
I know and understand the reasoning for this, I just don't like it. I am a BSD
fan, so I indulge in a land where such ABI breaks are possible. In a fantasy
land I would like to see the Linux community coming up with a way to deal with
ABI breaks. Not that I think such breaks are to be taken lightly but they are
sometimes necessary. Such as this case.

~~~
masklinn
The problem is because Linux is just a kernel (not an entire system like BSDs)
_the syscall ABI is the actual kernel API_. If you break it, you break the
world.

On BSDs, or Window, or most every OS, there's a base "userland" library (e.g.
libc) which serves as the kernel API and hides whatever ABI specific syscalls
use, Linux doesn't have that.

~~~
cesarb
That only moves the problem outwards; instead of having to keep compatibility
within the syscall ABI, you have to keep compatibility within the "base
userland library" ABI, which is probably much larger (for instance, printf is
not a syscall).

~~~
masklinn
> That only moves the problem outwards

It also moves it to a place where you can have somewhat abstracted types (so
chances are the client will work with just a recompile as it picks up the
updated typedef), you can much more easily prepare the transition by e.g.
using various flags or even trying alternatives beforehand (for instance OSX
originally added a stat64 call before before rollbacking that choice and using
macros to transition stat to 64b), and you are able to stop before a
completely mangled syscall is actually attempted (by checking for some version
symbol which must be set if you compiled for the 64b version of the various
syscalls).

------
coltonv
Is there a reason why they decided to store time as seconds from 1970? In a
32-bit integer nonetheless. It seems like basic logic would have lead the
original designers to make it at least 64 bits so that you'd never overflow it
(with a 64 bit time we'd be good til the year 292277026596).

64 bits would also allow you to also cover the entirety of history, all the
way back to 13.7 billion years ago when the Universe came into existence, but
instead the UNIX time format is shackled to be within ~68 years of 1970.

~~~
mikeash
If you told the original UNIX developers that there was even the slightest
chance their system might still be in use in 2038, they probably would have
called in some large, friendly men in white coats to haul you away.

Add to that the fact that memory was very much _not_ cheap at the time. Memory
for the PDP-7 (the first computer to run UNIX) cost $12,000-20,000 for 4kB of
memory. In 1965 dollars. In 2017 terms, that means that wasting four bytes had
an amortized cost of _three hundred to six hundred dollars_. And that's for
_each_ instance of the type in memory.

~~~
legulere
The year 2038 problem is actually younger than unix.

The first definition was 60th of seconds since 1970-01-01T00:00:00.00 stored
in two words (note that a word is 18 bit on a PDP-7!). That definition was
later changed.

Also Linus could have defined `time_t` to be 64 bit when he started linux.

[https://en.wikipedia.org/wiki/Unix_time#History](https://en.wikipedia.org/wiki/Unix_time#History)

[http://aaroncrane.co.uk/2008/02/unix_time/](http://aaroncrane.co.uk/2008/02/unix_time/)

~~~
smsm42
I'm not even sure there was a standard 64-bit type for C in 1991... Or how
well compiles on PC would support that.

~~~
caf
There wasn't - the largest minimum integer size from C90 (ANSI C) was long,
with at least 32 bits. "long long" was agreed upon at an informal summit in
1992 as an extension 64 bit type on 32 bit systems until it was standardised
in C99 (but already existed in several compilers at that point, including
GCC).

So GCC _may_ have had 'long long' already when Linus started working on Linux.

------
Jach
Let's move to Urbit's 128 bit system:
[https://github.com/urbit/urbit/blob/master/include/vere/vere...](https://github.com/urbit/urbit/blob/master/include/vere/vere.h#L762)

    
    
        /*  Urbit time: 128 bits, leap-free.
        **
        **  High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012)
        **  Low 64 bits: 1/2^64 of a second.
        **
        **  Seconds per Gregorian 400-block: 12.622.780.800
        **  400-blocks from 0 to 0AD: 730.692.561
        **  Years from 0 to 0AD: 292.277.024.400
        **  Seconds from 0 to 0AD: 9.223.372.029.693.628.800
        **  Seconds between 0A and Unix epoch: 62.167.219.200
        **  Seconds before Unix epoch: 9.223.372.091.860.848.000
        **  The same, in C hex notation: 0x8000000cce9e0d80ULL
        **
        **  New leap seconds after July 2012 (leap second 25) are ignored.  The
        **  platform OS will not ignore them, of course, so they must be detected
        **  and counteracted.  Perhaps this phenomenon will soon find an endpoint.
        */

------
gregmac
I wonder how much attention this will get from the general public and non-
technical managers? After all, programmers predicted doom for Y2k, and then
"nothing happened".

This is almost the same situation, except I assume slightly less
understandable to a non-programmer (you have to understand seconds-since-1970
and why we'd do that instead of storing the date as text, powers of 2 and the
difference between 32 and 64-bit).

~~~
gmac
Yeah, I worry that between the less obvious failure mechanics and the sense
that Y2K was overblown (probably, ironically, because it was effectively
mitigated), the epochalypse may not be all that nice.

------
fgandiya
Speaking of the 2038 bug, I'm impressed with Paul Ryan's rhetoric [0]

“I asked CBO to run the model going out and they told me that their computer
simulation crashes in 2037 because CBO can’t conceive of any way in which the
economy can continue past the year 2037 because of debt burdens,” said Ryan.

I love politicians.

[0]-[http://www.cnsnews.com/news/article/ryan-debt-track-
hit-800-...](http://www.cnsnews.com/news/article/ryan-debt-track-
hit-800-percent-gdp-cbo-cant-conceive-any-way-economy-can-continue-past)

------
goodplay
I Wonder how DRM anti-circumvention laws will mix with this; You have a
locked-down device you use, depend on, and know is defective, but you are not
allowed to hack the device to fix it.

------
lazyjones
Meh, we'll just redefine time_t as (signed) seconds since 2000 or so and
subtract 30 years in seconds from all timestamps ... ;-)

~~~
btilly
No, you make it time_t (unsigned) seconds since the epoch. That pushes the
problem out 70+ years and doesn't break any binary APIs.

~~~
simias
Changing from signed to unsigned is very much an ABI break.

~~~
btilly
Yes, it is an ABI break.

But if you took code that was compiled with each version, the binary data that
they will produce/consume for dates between the epoch and 2038 is bit for bit
identical.

------
steffan
Despite the cause being the end of the UNIX epoch in 2038, problems will
become apparent a much sooner. Like the Y2K issue - in ~2031 (or sooner),
systems that track expiration dates or contract terms will start to run into
dates past 2038. As 2038 approaches, more systems will be affected (there are
relatively fewer expiration dates 7 years out vs. 5 or 3).

The effects of this problem are closer than they seem - only 14 years away or
less

------
pkulak
Is 2038 the end of a signed int? If so, can't we just make it unsigned and buy
ourselves another 70 years or so? I don't know how much of an issue not being
able to represent time before 1970 is, but for timestamps that doesn't seem
like it would be an issue.

~~~
Zitrax
That would break systems that relies on time stamps earlier than 1970 though.

    
    
      int main(void)
      {
          time_t epoch = -100;
          printf("%s", asctime(gmtime(&epoch)));
      }
    

The above would for example print a time in 1969.

------
mrkgnao
> BSD-based distributions have the advantage of being able to rebuild
> everything from scratch, so they do not need to maintain user-space ABI
> compatibility in the same way.

I don't understand, not knowing much about BSD. Is this an LTS/support thing?
Can someone explain?

~~~
cbr
Generally people build BSD packages from source instead of installing
binaries. (I think; I've not used BSD.)

~~~
clarry
OpenBSD user since 2009. I have _never_ compiled a package from source.

But they can break the ABI because they do not want to maintain compatibility
with old proprietary binaries. It's a source world, in the sense that any
software can and will be recompiled if and when needed. That doesn't mean
every user has to compile their own system.

------
paxswill
Newton (Apple's old PDA) had a similar problem in 2010 [0]. In short, while
the base system and C++ interfaces used 32-bit unsigned ints with a base of
1904-01-01, NewtonScript uses 30-bit signed ints, with a working base of
1993-01-1, overflowing in 2010. The fix was a binary patch that changed the
time bases.

0:
[http://40hz.org/Pages/Newton%20Year%202010%20Problem](http://40hz.org/Pages/Newton%20Year%202010%20Problem)

~~~
userbinator
It's interesting to see that Apple's... shortsightedness/planned obolescence
is nothing new. The Apple Lisa, released in 1983, was apparently not designed
to survive beyond 1995:

[http://www.macworld.com/article/2026544/the-little-known-
app...](http://www.macworld.com/article/2026544/the-little-known-apple-lisa-
five-quirks-and-oddities.html) (scroll down)

------
equalunique
Surprisingly, when Googling for 2038 & FreeBSD, the 2nd highest recommended
search result was:

2038年問題 freebsd

I do not speak, write, or search for things using Chinese characters. Seems as
though this problem must have been heavily Google'd for by Chinese speakers -
why else would it have popped up in my search recommendations?

Btw: Google Translate tells me 年問題 means "year problem"

Perhaps this information was important for ensuring the safety of Kylin, which
started out as a sort of Chinese DARPA-style project to get the state off of
MS Windows. Kylin was announced in 2006. It was supposedly based on FreeBSD
5.3.

Strange thing is, Kylin later became known to use the Linux kernel (with a
Ubuntu influence). - Google search recommendations, which should be based on a
recent volume of searches, if they did suggest anything about Kylin
development, should yield "2038年問題 linux" rather than "2038年問題 freebsd" \-
Maybe some of those FreeBSD-Kylin systems are still being heavily used.

Or perhaps there are a lot of embedded systems being produced in China which
use FreeBSD.

------
sixdimensional
On a side but related note, I don't understand why many programming languages
and databases don't have a positive and negative infinity date
placeholder/token value that is standardized and cross platform. Negative
infinity date is "past", positive infinity date is "future". This would solve
the common problem of what date to use when you are trying to talk about
unknown date in the future or unknown date in the past, rather than using
weird placeholders like 9999-12-31 or 1900-01-01 or other magic numbers.

~~~
rwallace
There are lots of scenarios where you need to represent an unknown/indefinite
date, but this can be done with null; are there any reasonably common
scenarios where you need to distinguish between unknown past and unknown
future in the same context?

~~~
sixdimensional
I agree, null is often chosen as an option. But null is also not a value by
definition so then it becomes hard to do a range check when using say, a start
and end date. Also, what is the difference between a date in the future and
null? Semantics I think-a token future date has an explicit value, whereas if
you use NULL, the use of that as a future date has a new implicit value that
depends on context.

I know maybe it sounds pedantic or perhaps out there but I think that token
dates that are fixed and specified as positive or negative infinity gives a
mathematical value that can then be reasoned with formulaically, just like we
do with calculus. We keep running into finite limits which is what keeps
causing problems such as Y2K, Y2K38, the beginning of Unix time (1970-1-1) -
maybe if we treated the beginning and end of time as infinity some new method
of reasoning about dates would become more apparent. I'm not sure as I haven't
gone all the way down the rabbit hole with this idea yet.

~~~
sixdimensional
Another thought - if you treat a date as a relative variable related to a
frame of reference (example, what if you defined the future to be a token
value of today + N days, which means it is always calculated as a dynamic
future date ahead of today), maybe we could reason about relative past and
present using relative variable dates? Or maybe this is just crazy talk.

------
mring33621
More gravy for Initech!

------
runeks
Using a 64 bit unsigned integer with nanosecond resolution gives us 585 years
(2^64/1e9/60/60/24/365) after 1970 to come up with a new format. This,
combined with using some other format to describe dates before 1970, seems
like a sensible solution to me.

------
Walkman
The problem is not with developers or tech savvy people. Everyome will know
about this by then and solutions will be applied. The problem is with end
users, who will only realize this after the shit hits the fan and their fridge
will go crazy or there will be a car crash.

~~~
tgsovlerkhgsel
This assumes that any of today's technology will survive 21 years...

~~~
5ilv3r
My jeep is 27 and has an intel CPU.

so.... yep.

------
granfalloon
So what are we calling this one, Y2K38?

I've heard people talk about the risk to cars, but what other kinds of
embedded systems will still be in use after 20 years? Maybe certain industrial
machines?

------
jwatte
[https://news.ycombinator.com/item?id=7678847](https://news.ycombinator.com/item?id=7678847)

------
jayflux
This maybe a stupid question, but could we not use Bignum as a datatype to
solve this? or would it be too computationally expensive?

------
snvzz
This is a good reason to run anything but Linux, particularly on 32bit
hardware.

All BSDs have, as far as I'm aware of, solved this years ago.

~~~
throwaway2048
only netbsd and openbsd, still an issue on freebsd.

------
Spooky23
Fortunately, my retirement system has a project active right now to address
this, and I will be retired in late 2032.

------
amelius
Y2K didn't cause any serious blips on the stock market, so 2038 will probably
pass without many even noticing.

------
halcyondaze
As a layman here, can someone explain this what the significance of the year
2038 is to me?

~~~
soundwave106
[https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

Short summary: Many systems (including Unix) store time as a signed 32 bit
int, with the value 0 representing January 1st 1970 00:00:00. This number will
overflow on 03:14:07 UTC on 19 January 2038.

~~~
halcyondaze
So a more serious Y2K?

~~~
soundwave106
It is Y2K-ish; it's "different" so I'm not sure about seriousness. I'm
thinking it simultaneously could be easier and more difficult, the standard
"it depends" type answer. :)

Y2K is more of a formatting / digit representation problem than a pure data
type overflow. The solution for Y2K was to switch the _representation_ of year
from 2 to 4 digits, along with coding and logic changes to go along with this.

For Unix / Linux, the solution for the 2038 problem involves changing time_t
from 32 bits to 64 bits. At a higher level (eg what's in your C++ code),
instinctively I don't think this in itself would involve as many code changes
(maybe some data type changes, but probably less logic changes than Y2K,
that's my guess). I believe several platforms have already moved towards 64
bit time_t by default... some support this by default even on 32 bit systems,
such as Microsoft Visual C++ -- [https://msdn.microsoft.com/en-
us/library/3b2e7499.aspx](https://msdn.microsoft.com/en-
us/library/3b2e7499.aspx)

Since this involves a data type overflow issue, though, we're dealing more
with platform specific / compiler / kernel type issues. I don't know, for
instance, how easily 32 bit embedded type systems could handle a 64 bit time_t
value. I understand that there are some technical issues with Linux kernels
(mentioned in some of the comments) that prevent them from moving to a 64 bit
time_t irregardless of platform (time_t should always be okay on 64 bit
platforms, it's the 32 bit platforms that will have the issue...)

The good news is we have 21 years to think about it...

------
njharman
My retirement, only 18 years away. I'm real sorry I'm gonna miss this mess,
NOT!

------
spencermountain
for the others curious, seems javascript handles dates with 64-bit floating
points, which have a maximum of 9007199254740991.

The highest date I could make with node+chrome was 'Dec 31 275759', which
cozies-up pretty close to that (8639977899599000)

~~~
jamescgrant
I wanted to figure out the importance of that value you found, so I went and
did some further research. It turns out the greatest date you can create in
Javascript is Date(8640000000000000). Interesting!

From the ECMAScript Spec [1]:

 _The actual range of times supported by ECMAScript Date objects is slightly
smaller: exactly –100,000,000 days to 100,000,000 days measured relative to
midnight at the beginning of 01 January, 1970 UTC. This gives a range of
8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC._

[1] [http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1](http://ecma-
international.org/ecma-262/5.1/#sec-15.9.1.1)

------
AndrewKemendo
Can someone ELI5 this please? The only thing that seems comparable that I know
of was the "Y2K bug" \- but reading through this it seems like this is
actually a big problem - as opposed to the techno-illiterate panic of Y2K.

 _That work, he said, is proceeding on three separate fronts_

I can't read that without thinking of the turbo encabulator.

~~~
minikites
I'll let somebody else handle the explanation but Y2K wasn't a "techno-
illiterate panic", a ton of people worked a ton of hours to fix and update the
code for Y2K and it's a testament to their labor that there were no major
issues.

~~~
magpi3
It was a combination of both. I still remember my dad coming home from a talk
that he considered the "best yet" on the Y2K issue.

The speaker warned that traffic lights would stop working. Maybe someone more
techno-literate than me can explain why that would be a genuine concern, but
from my perspective at the time it seemed like the guy was making money from
fear mongering.

------
shurcooL
Is software written in Go (that uses "time" package) going to be affected?

~~~
jayflux
No, [https://golang.org/pkg/time/#pkg-
constants](https://golang.org/pkg/time/#pkg-constants) Not unless you
explicitly use the Unix method

------
kebman
Hey guys! I just invented a new form of music! :D Epochalypso!

------
pagade
What about NTP epoch which has 2036 problem?

------
Practicality
Here I thought it was a post on the singularity. It might be ironic if all the
AI starts running into all sorts of 2038 bugs and this ends up being a huge
issue.

------
miesman
With any luck I'll be dead by then.

------
rbanffy
We should stock up on IBM 5100's

------
carapace
(Does anybody remember that time traveler?)

------
grabcocque
And IPv6 penetration will have hit 20%.

~~~
deathanatos
You jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if
linear growth is presumed (and it's actually been growing closer to
exponentially, as would be expected) we should hit 20% late this year. I'm
hopeful that we'll see some decent pickup of it since AWS _finally_ started
offering it.

This is global adoption; some countries, including the United States, have
already hit 20%.

[1]:
[https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

~~~
marcosdumay
What's up with that huge weekly variation?

~~~
mastax
It looks like it's correlated with the weekend. I guess workplace computers
are more likely to use IPv4? It makes sense on the surface. Workplaces have
little to no incentive to use IPv6 since they either have a huge block of IPv4
space or run NAT or both. Also they tend to rely more on enterprise network
appliances which have bad IPv6 support in my experience. IPv6 is more of a
boon to consumer applications since carrier-grade NAT is a nuisance and
otherwise you need an IP per customer.

~~~
deathanatos
Every employer except one that I've worked for had IPv4 only. None of them had
public IP blocks; they were all NAT'd.

> _Also they tend to rely more on enterprise network appliances which have bad
> IPv6 support in my experience._

This I would believe.

> _IPv6 is more of a boon to consumer applications since carrier-grade NAT is
> a nuisance and otherwise you need an IP per customer._

It would have been a slight boon at work, too. HR perennially makes me grab
documents/data off my home machine, and I cannot wait for the day when I can
just `ssh` to a domain name. My .ssh/config aliases are getting pretty good,
but it still adds considerable latency to pipe everything through a gateway.
(Alternatively, I could run SSH on non-standard ports, but I've yet to get to
mucking around with the port-forwarding settings for that.)

There were also times when we needed to do stuff like employee laptop-to-
laptop communications, and the network just wouldn't deal with it. I was never
sure if this was NAT, or just that Corp Net liked to drop packets. (It seemed
rigged to drop basically anything that didn't smell like a TCP connection to
an external host. ICMP wasn't fully functional, which of course makes
engineering more fun when you're having your personal desktop at home do pings
or traceroutes for you, but that doesn't help if the problem is on your
route.)

------
madphrodite
Will be 70 and happily oblivious.

------
DoodleBuggy
Y2K round 2

------
geoffreyhale
Y2K

------
iamgopal
Call me stupid, but I think computing will be much different to worry about
this. ( single chip os or iot to the level that each hardware component is
separate, or something else...)

~~~
njharman
> Call me stupid,

Well I won't say you are stupid. But do you realize we are talking about a
time format "designed" 40+ years ago. And some cpus are still compatible with
chips from 80's 90's. To imagine all that will go away and be solved in 20
years is not logical.

Also, the problem isn't with PCs (which will be upgraded) but the billions of
IoT, industrial controls, and other embedded devices that lack easy upgrade
paths. Things like elevators, pressure release valves, cars.

~~~
keithpeter
I'd add trains to your list. There are locomotives in use in UK that use
electronics (I admit not microprocessor based and not running an actual
operating system) dating from 1980s. The ones currently being designed may
have similar active service times.

