Summary of the 2038 BoF at DC17

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.

https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index....

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.

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.

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.

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