Summary of the DebConf 2038 BoF

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.