
The end of an Era – changing every single instance of a 32-bit time_t in Linux - zdw
https://www.linaro.org/blog/the-end-of-an-era/
======
Edward9
This team did an amazing job that will most likely go completely unnoticed if
they are successful

~~~
legooolas
Isn't that the point of such fixes?

(And also why a lot of people thought that the Y2k but was over-hyped, when
there was a _lot_ of background work which fixed the problems so few people
noticed when it did come to roll-over time)

~~~
eru
Y2k was definitely overhyped.

Yes, lots and lots of background work went on. My grandfather made a nice
chunk of cash from being able to work with some near extinct programming
languages and assembly variants on obsolete machines.

But: the hypetrain wasn't so much focusing on glitches in banks and insurance
companies, but on catastrophic failures in missile control software etc and
embedded systems that often don't even have any concept of date.

~~~
bluGill
It wasn't overhyped, but you are correct that most of the hype was wrong

~~~
eru
Oh, I'm not denying that some hype was justified. Even a very big hype.

Just not as big a hype (and of the wrong type!) as we saw.

------
bArray
I love how Unix concepts have been around so long that their initial
representations and assumptions of time will soon break. I wonder if the
engineers at the time thought that programmers in the future will run into
such issues. Perhaps 64 bit time will also cause some headaches in the far
future!

I was also trying to think of other computing implementations/assumptions that
have shown their age. We've see a decrease in support for 32 bit CPUs, we ran
out of addresses in IPv4, much security became obsolete - any others that come
to people's minds?

~~~
adrianN
Booting a modern CPU is a bit like time traveling through all eras of CPU
architecture.

~~~
JdeBP
Only in the Intel Architecture and only then if one is bootstrapping in the
old way. It is quite possible for a machine with EFI firmware, and no need of
compatibility support, to go straight from the initial unreal mode to
protected mode, never entering real mode.

------
westurner
Thanks!

Year 2038 Problem > Solutions is already updated re: 5.6.
[https://en.wikipedia.org/wiki/Year_2038_problem](https://en.wikipedia.org/wiki/Year_2038_problem)

------
moviuro
Welcome to 2014! /s [0]

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

~~~
yjftsjthsd-h
This is actually an interesting case study in different systems and how they
deal with these things. OpenBSD has a smaller community of developers, an
overwhelmingly strong focus on correct code and a willingness to break things
if it helps. Linux, on the other hand, has probably orders of magnitude more
developers, but is obsessed with backwards (ABI) compatibility and has a
harder time coordinating changes.

------
tyingq
MySQL appears to still be mulling it over.
[https://bugs.mysql.com/bug.php?id=12654](https://bugs.mysql.com/bug.php?id=12654)

~~~
rini17
MariaDB: "Use DATETIME as a storage type if you require dates beyond this."

[https://mariadb.com/kb/en/from_unixtime/](https://mariadb.com/kb/en/from_unixtime/)

...so it may end up that nothing will be fixed, just TIMESTAMP will get
deprecated.

~~~
ars
Timestamp automatically handles the timezone, datetime does not.

They are not interchangeable.

One is used to record an instant in the world, the other to record a specific
number for display back without modifying it because of changes in time zone.

------
basementcat
I for one am glad that some sparc kernel bugs got fixed.

------
akie
Fantastic! Thank you so much for taking care of this.

------
ncmncm
Meanwhile, the unsigned 32-bit count of seconds (also) since 1970 used in pcap
output from tcpdump, and used universally throughout the financial industry
with no hint of a move away from it, will not roll over until 2106. If they
are still in use then, code will interpret small values as implying a time
after 2106, rather than as an ancient historical time before 2000.

It is hard to know why anybody thought it so urgent to go to 64-bit seconds
counters for internal use in the kernel.

~~~
zrav
> It is hard to know why anybody thought it so urgent to go to 64-bit seconds
> counters for internal use in the kernel.

I routinely encounter systems running 15-20 year old kernels. Given that, NOW
is the time to fix the 2038 problem.

~~~
loeg
Note that 2106 is about 86 years from now — quite a bit more than 15-20.

Also, 20 years ago was before the Linux 2.4 kernel. You encounter systems
running Linux 2.2 routinely?!

~~~
leoedin
There's at least a couple of reasons that doesn't apply.

Software projects don't develop linearly. 20 years ago the Linux kernel was 8
years old, today it's 28 years old. The motivation to upgrade the relatively
mature 2020 kernel will be much less than that to upgrade the immature 2000
kernel.

And perhaps the biggest one - computers have changed. 20 years ago a PC that
could run Linux was a big power hungry thing. Today it's the size of a box of
matches. Embedded Linux PCs with limited upgrade paths are _everywhere_ today.

When I worked on satellites (stopped in 2015) we'd routinely use electronic
test equipment which was running an embedded version of Windows 98. Given that
the stuff shipping today is even further down the maturity curve, I think it's
almost certain that it'll be used in 20 years (if it still works).

