Start working on addressing the Y2038 problem.

[zrax]

Plasma uses 32-bit timestamps in a few places, which will start causing problems in a little over 12 years... However, we don't want to break backwards compatibility with the wire or file protocol, so this introduces a new encoding which remains backwards-compatible until Jan 2038:

• For timestamps before max(int32), the same 32-bit encoding is used.
• For timestamps greater than max(int32), a dummy 0xFFFFFFFF value is written, immediately followed by a 64-bit (signed) timestamp. This is compatible with the definition of time_t on systems that use a 64-bit timestamp.

This means things will continue to work even with unpatched servers and clients until the rollover point, which should hopefully give enough time for everything to be updated and patched before crashing and burning.

This change specifically addresses the 32-bit timestamps everywhere plUnifiedTime is used, and in the Vault nodes. There are other 32-bit timestamps left to convert (such as the server ping timers, and probably others I'm forgetting about), but it's a start.

[dgelessus]

This is definitely something that should be addressed at some point, considering how long Uru has stayed around so far 😄

I've also been thinking about possible workarounds for this issue. As a first step, wouldn't it be enough to ensure that all 32-bit integer timestamps are unsigned rather than signed? That would buy us extra time until 2106 without changing the structure of any data formats. Because Plasma came into existence in the late 1990s, there should be no existing data that contains timestamps before 1970. Some timestamp fields already seem to be declared as unsigned 32-bit (though I haven't checked if they get implicitly cast back to signed elsewhere).

I'm of course thinking about long-term compatibility with existing servers, mainly Cyan's closed-source MOULa server, which I assume will never receive an update to support a new data format like this. Whereas if the field size stays the same and we only redefine the meaning of the values, all existing de-/serialization code will continue to work in principle. Whether this is safe of course depends on how much the server code looks at timestamps - if old code does a signed comparison of a pre-2038 and post-2038 timestamp, it will misbehave.

[zrax]

Yeah, that's certainly an option too... It means that any conversions to/from time_t will need to be handled carefully, and we'd probably still need to require that time_t is >= 64-bits for semantic compatibility. I don't know if the closed-source server code would ever get updated for either an unsigned timestamp or a protocol change, but I figured they have 12 years to either work on it or become obsolete ;).

Either way, we should be consistent with either the extended 64-bit encoding or the unsigned 32-bit encoding wherever timestamps are serialized... What do others prefer?

[dgelessus]

I agree that it would be good to move to 64-bit timestamps internally as much as possible (then they can also remain signed if that's more convenient). I'm only worried about backwards-incompatible additions to external data formats, when there's an alternative that is "probably" safely backwards-compatible.