Year 2038 problem

[darrenfoong]

I observed from the white paper and TemporaryID that the startTime and expiryTime are effectively 4 bytes, i.e. Unix time (seconds).

Since this will overflow on 19 January 2038 (18 years later!), if we want BlueTrace to still be used during pandemics then, we should fix this and use 8 bytes instead.

[ramsestom]

The overflow is not an issue unless you want to monitor and keep history of a user contacts for more than 18 years (which doesn't make sense in any epidemic context. The data are kept no more than 21 days in TraceTogether for example)

[harishpillay]

Betwen 18 Jan 2038 to 20 Jan 2038, the epoch time will reset to 0. I think the server code has take care of that. Yes, I would agree that it is better to fix it in the system globally.

Some background reading: https://opensource.com/article/19/1/year2038-problem-linux-kernel

[crjacinro]

Is there a way to implement the fix to 8 byte but still backward compatible to the existing 4 byte system?

[CarsonRedeye]

Long in java is 64bit. Therefore it is not an issue on Android side.

[darrenfoong]

Yes, it was a bad idea to create the issue in this repository; the problem is with the protocol design, not the Kotlin code.