Summary of the DebConf 2038 BoF [LWN.net]

Summary of the DebConf 2038 BoF

Posted Sep 4, 2017 8:48 UTC (Mon) by hifi (guest, #109741)
Parent article: Summary of the DebConf 2038 BoF

Could someone point out *why* it hasn't been as easy as to decide to introduce a new "time64_t" and other time related structures as well?

It feels like the most straightforward solution and that it could one of the easiest one to implement. It does not just move the issue by some years, it moves it ridiculously far away it doesn't matter anymore. It also helps fixing up old applications with less hassle as they have been built with UNIX time in mind to begin with so the epoch doesn't change for them. Sure, it requires going through a lot of time related code because other parts of such applications will likely use 32 bit integers to store time related values and binary file formats or protocols but that's besides the point.

Only thing that needs to be done then is to make sure for ABI compatibility that the old ones exist and work (and fail) like they would today and deprecate them as fast as possible.

In-kernel things, filesystems and other pieces of code can be updated bit by bit as both work simultaneously. For testing purposes the new time64_t could be exposed today even if we're still actually counting time in 31 bits but expose a 64 (or 63 keeping signedness?) bit interface.

Am I thinking too small here or has this issue been blown out of proportion?

to post comments

Summary of the DebConf 2038 BoF

Posted Sep 4, 2017 10:15 UTC (Mon) by joib (subscriber, #8541) [Link] (1 responses)

I think this is roughly the plan yes (that is, introduce time64_t etc.), analogous to how large file support was handled with attendant macros (_FILE_OFFSET_BITS=) etc.

The problem is that there's a *lot* of stuff that embeds time_t somewhere (structs, ioctl's etc.). So it's a lot of work, for little immediate benefit. Particularly for workstation/server users who are already on 64-bit systems where time_t is 64-bit so this is a non-issue for them. The problem really only affects embedded where most likely a lot of 32-bit systems will be around by 2038.

Summary of the DebConf 2038 BoF

Posted Sep 4, 2017 10:23 UTC (Mon) by joib (subscriber, #8541) [Link]

> Particularly for workstation/server users who are already on 64-bit systems where time_t is 64-bit so this is a non-issue for them.

To clarify, the size of time_t is not a problem for these users. Other y2038 issues like on-disk timestamps in filesystems etc. certainly affect them as well.

Summary of the DebConf 2038 BoF

Posted Sep 5, 2017 7:44 UTC (Tue) by ledow (guest, #11753) [Link] (2 responses)

Because many protocols and filesystems weren't ever built with that in mind and need a total on-disk / on-wire format redesign to accommodate it.

Everything from NTP to FAT will have to be changed, in a non-backwards-compatible way, and in most cases will break ALL interaction with other systems (e.g. NTP servers, storage devices) when you do so.

The "solution" is obvious. Any number of ways to fix it. The problem is implementing the solution in a way that allows people to keep using their computers.

Case in point - You have old tape systems with historical data on them, filesystem-dated, etc. (research data, archives, mortgage information, etc. etc.etc. - the era where timestamps were not duplicated into the files because it just took up unnecessary space, and you used old filesystems because you didn't have room for 64-bit values). You "upgrade" the filesystem modules to something new that allows you to move to 64-bit. You read an old file, and have to convert that date (from 1970 -> 2038) into the modern format. How do you ensure that - post-2038 - you know whether that file was really made in 1970 or 2038? Sure, newly-created file will be post-2017. But old ones? Are you going to silently trash the date fields for your users? "But they shouldn't be using them?" They why have them? And is your system going to think it's not been backed up in 40 years?

Or do you stop everyone's NTP server working with the established standard? Or does any NTP device now have to be redesigned? Or are you going to try to negotiate a compatible protocol with very expensive GPS / atomic clocks / etc. timekeeping devices running things like stock-exchanges, that were designed years before any such negotiation / protocol exists? Is the user just going to be told "Sorry, bin it." and have to buy a new one? I'm sure the manufacturers would love it, the users not so much. In fact they might just push back and say "I'm not going to upgrade my OS then, until 2038, and get another 21 years of usage out of this ridiculously expensive box".

It's not a "technical" problem, it's a practical one.

It's literally a case of trying to get users to move from "something that will work for another 21 years" to "something that will mean you have to spend lots of money and effort now". Sure, common sense would dictate the answer, but try running that past your company accounts department. "We have to spend this money now". "Why?". "Because if we don't, in 21 years time we might have the exact same problem but be 21 years closer to a solution and all our competitors will be having to do the same at that point anyway".

It's not quite as simple as just extending the timestamp field. It's breaking lots of entirely unrelated protocols. Will SMB1/2/3 wire protocols have to be redesigned? NFS?
NTFS? Word documents (what date format do they save in? Is it going to think the linked Excel file hasn't been updated in 58 years and refuse to honour it? TLS certificates? DHCP leases? Kerberos tickets? 32-bit dates are EVERYWHERE, and it's not a case of "just fix it in the kernel and everything is fine", it's literally getting the entire software library to be compliant, compatible, and able to read all its historical data too, without trashing data or even metadata the user may be relying on.

And there are LOTS of hidden dates. Do you know if the date used for the last replication of a HyperV/VMWare/etc. VM is 32-bit or 64-bit? I'm not at all sure I do. Maybe my VMs will decide the replication is too old and just stop? Or maybe it will force a simultaneous, all-VM immediately replication that then can't complete because the tickover confuses it?

Y2K is going to look like a party in comparison, and that cost billions and was relatively well-known to even ordinary users. Y2K38 is literally everything that ever touches a data being broken or unknown until someone redesigns the file format, network protocol or interaction with hardware.

Summary of the DebConf 2038 BoF

Posted Sep 5, 2017 8:55 UTC (Tue) by hifi (guest, #109741) [Link]

> Because many protocols and filesystems weren't ever built with that in mind and need a total on-disk / on-wire format redesign to accommodate it.

The protocols and binary formats need to be changed by application developers and that's a different issue from adding new 64 bit time types.

> You read an old file, and have to convert that date (from 1970 -> 2038) into the modern format. How do you ensure that - post-2038 - you know whether that file was really made in 1970 or 2038?

Expanding the UNIX time from 32 bit integers to 64 bit integers does, in fact, keep backwards compatibility. You read the old file and the integer timestamp is still valid even in 2038, it just happens to fit in the leading 32 bit portion of a 64 bit timestamp. Both share the same epoch so there's no need for actual conversion.

> It's not quite as simple as just extending the timestamp field. It's breaking lots of entirely unrelated protocols.

On the kernel and system side, it should be. You create new 64 bit types that are backwards compatible up to INT32_MAX and call it a day. The actual work is on application side like you said.

The thing I don't understand is why we need to scramble about *what* the new type will be when the simple, obvious and backwards compatible choice is right under our noses. The effort should be spent on fixing applications and drivers and not pondering if we need a new epoch or representation format.

Summary of the DebConf 2038 BoF

Posted Sep 5, 2017 13:23 UTC (Tue) by willy (subscriber, #9762) [Link]

You're exaggerating a little:

GPS time rolls over every 19 years (1024 weeks). Next due in April 2019.

NTP rolls over in 2036. It's not anticipated to cause any confusion (the protocol may have been modified by then to have 64bit seconds, but even if it hasn't, there's no confusion in the protocol. Implementions may have bugs, of course)