
Summary of the 2038 BoF at DC17 - edward
https://lists.debian.org/debian-devel/2017/09/msg00035.html
======
twic
> In terms of things like on-disk data structures, don't try to second-guess
> future interfaces by simply adding padding space for a 64-bit time_t or
> equivalent. The final solution for time handling may not be what you expect
> and you might just make things worse.

That's pretty unhelpful.

I'll give different advice: store time as leap-second-corrected milliseconds
since the standard epoch in a signed 64-bit field. If the Linux maintainers
eventually come up with something wacky, write conversion code.

This is the standard format in the Java/JVM world. You might not care about
that world, but it at least means this format isn't going away. Any new time
convention has to be compatible with this because of the sheer amount of stuff
it would break if it wasn't.

------
gbrown_
If you're interested in 64-bit time you may want to checkout this OpenBSD
presentation.

[https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index....](https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html)

------
sverige
>We can't just replace all the existing interfaces with 64-bit versions, of
course - we need to continue suporting the existing interfaces for existing
code.

The backwards compatibility problem in a nutshell. You can put off breaking
stuff today and kick the can down the road some more, but where does it end?
January 19, 2038?

I think it boils down to a philosophical difference, not really a practical
difference, despite the inevitable arguments that "we can't just go around
breaking all the shit that's already deployed." Even though the pain would be
greater short-term, the benefits of breaking stuff today almost always
outweighs the hazards of putting it off indefinitely, since there's almost
never any motivation for going back and removing the workarounds once a stable
solution is implemented. As evidence, OpenSSL is Exhibit A.

------
virtuallynathan
I can't help but think this is going to go very badly in 2038. The number of
computers that might deal with time in the world is a very scary thought.

~~~
lathiat
Given that many simple elapsed timer interfaces work on tracking timestamps,
yeah.

------
kator
When Y2K got hot I told all my team members that 2038 would be worse. At least
Y2K was easy for humans to understand, they all could see 1999 => 2000 and how
that seemed important. I had bank CIO's and large movie studio CIO's calling
me with "unlimited budget to fix this". Because it was easy for their CEO and
CFO to understand.

The challenge here will be that this seems awkward from a non-computer science
standpoint. Have you tried to explain this to your Mom yet? It's obvious to
bit heads but not regular humans. Even my own very technical team thought I
was a bit off my rocker talking about this in 1999.

The other very real challenge is the generation gap, many devs working on
stuff today have no experience with Y2K issues, they just haven't been working
on systems long enough to be bitten by that stuff. They look at old code where
some "if (yy < 69)" hack was put in place to support old YYMMDD formats and
wonder what the crazy dev was thinking when they pushed that code.

On top of all these issues we have IOT being deployed by brilliant young minds
who have no experience dealing with things that have to work for 50 years
plus. If anything, the IOT ecosystem is moving to a "technology consumer"
mentality where things are built to barely survive 18 months and everyone is
moving so quickly they don't worry about 2038 because "it's eons from now".
Most of these companies won’t be in business in 2038 but their products will
litter the world and still be plugged in bashing away at whatever the internet
is by then.

The velocity of this decade is amazing, I stand in awe as I watch all the new
technologies that get cranked out in rapid succession. However much of that
has been due to the "fail fast, iterate rapidly" approach. Which is great in
many ways, but formal verification has taken a back seat while most teams have
no engineering review team. These things slowed us down in the past and we
have rightfully tossed them over our shoulders in the ever rapidly
accelerating pursuit of innovation. However, we have lost of a lot of what it
really means to be an “engineer” along the way.

Hacking is great, until it gets someone killed. Thus far software has eaten
most of the world that doesn’t kill people. Now we tread into the world that
will, the physical world, self-driving trucks, trains, planes, automobiles.
Coffee makers that boil over and burn a four-year-old kid who just thought it
was fun to push the red thing on dad’s tablet. This is the world we are headed
into, and the 2038 problem is really just the tip of the iceberg.

I can tell you the Y2K problem was real, it was painful but easier for humans
to understand. If we want companies to prioritize resources to fix 2038
problems now over the next shiny button they want in their UI we will need a
massive marketing campaign to get people to understand. Because in the end
devs don’t make all the decisions on resource allocation and the people who do
have no clue how things really work. It’s an age-old tension between the
technologists and the business leaders. How we overcome that here is unclear
to me, but I think the basic issue is getting people to understand the
potential impact so it comes up in conversations in the Board Room and the CEO
is asking the CIO/CTO “So what are we doing about 2038?”. Otherwise nothing
will happen on the corporate side.

------
lathiat
This reminds me that I wanted to look at increasing the size of the username
in /var/log/{btmp,wtmp} which currently is only 8 characters - this output
powers "last" and "who".

But the on-disk format is based on the struct as defined in the headers.
They'll need to expand that for 64-bit so thought I could try backload the
change on that same period.

~~~
JdeBP
The headlined article is about Debian, and in Debian the field is _not_ 8
characters wide.

* [https://manpages.debian.org/stretch/manpages/utmpx.5.en.html](https://manpages.debian.org/stretch/manpages/utmpx.5.en.html)

------
carapace
Does anyone remember the alleged time traveler that came back to get a machine
that could somehow handle the 2038 problem?

~~~
gremlinsinc
sure do - John Titor... I still think of him often he was an interesting piece
of internet history/culture...and brought up lots of interesting
questions...never did have that 2008 civil war...but 2017 looks close...lol

~~~
carapace
That's the one. Cheers!

------
virtuallynathan
I started on:
[https://github.com/y2038/y2038-list](https://github.com/y2038/y2038-list)

PRs welcome, not sure how much time I have to do the research.

------
sgt101
The most important thing for now is to start to work out and track where
devices are so as to be able to be sure to get them when the time to sort this
out arrives (2028?)

~~~
JdeBP
When this came up in
[https://news.ycombinator.com/item?id=13922419](https://news.ycombinator.com/item?id=13922419)
it was in the context that cars and other items being bought _now_ have
expected lifetimes beyond 2038.

------
fulafel
This is 32 bit on a minority of systems - time_t is 64 bit on most 64 bit Unix
systems including Linux

~~~
DanielShir
Not necessarily. Using a 64-bit system and think you're safe? But what if the
binary you're running has been compiled for a 32-bit system? What if this is a
cloud service you're not even aware of?

As a true example here, my parents' house uses a simple computer to automate
watering of different places in their garden. Looked the chip up, 32 bit
system. So this will definitely stop working on Jan 2038.

This is just the tip of the iceberg. 2038 is going to be a big issue.

~~~
sverige
If the tip of the iceberg is automatic watering of gardens, the iceberg is
nuclear power plants designed to run on PDP-11s.

~~~
zeckalpha
PDP-11s are 16-bit computers...

~~~
sverige
...which control at least one plant in Canada (though recently it was replaced
with an emulation.)

And apparently they solved the 16-bit data problem, but maybe not the 32-bit
date problem.

 _" A current generation DCC system resides at L3 MAPPS' main Montreal, Canada
facility and is used to provide support to all participating COG members until
2035."_

[http://mapps.l3t.com/candu-plant-control-
systems.html](http://mapps.l3t.com/candu-plant-control-systems.html)

