The MCA (Anvil) file format has the following data in the headers:
Cluster 0: Location and size of chunk data.
Cluster 1: Date stamps of last modification for each chunk as 32-bit integers
These 32-bit integers are expressed as the number of seconds since January 1, 1970, and these file modification times are showing their age. (Recent files would have values around 5E 00 00 00 hex.)
These 32-bit integers are not currently a problem, but they are deprecated. They will be problematic when they reach 80 00 00 00 hex in January, 2038. They could be treated as negative numbers and any comparisons would fail.
Linked issues
is duplicated by 1
Attachments
Comments 5
The 32-bit dates are still there in the second chunk of region files (0x1000 to 0x1fff), therefore it is still an issue.
The exact issue concerns the possibility of integer overflow when signed 32-bit dates roll over to negative numbers on 2038-01-19 (13 years from now). I have no knowledge of how these dates in anvil files are used, but if they are ever compared to anything at any time, the comparison could fail after that date due to overflow of signed 32-bit integers.
See Wikipedia article here: https://en.wikipedia.org/wiki/Year_2038_problem
I recommend giving this report a very low priority for the next few years until the need for 2038 compliance checking becomes more relevant.
Keep in mind this issue will affect all worlds in all affected versions. I'm not sure if current/previous versions will be playable after January 19, 2038. It should be possible to test by changing your system clock, however.
I propose a fix depends on how this number is used internally, if used internally, either increase the value from 32 bits to 64 bits, this requires bringing out a new file format and will break a lot of pre-existing code, I would personally advise against this.
Instead, consider either no-longer using this number. Or, using it as an “abstract” relative number from some abstract point in time, and treat it as such. The time bought with this approach may be doubled by using an unsigned 32-bit integer instead, if negative numbers aren’t used.
This is unlikely to require a new file format version, and can be properly communicated. For third-party parsers this is likely still a change, since now they must handle slightly different logic for file versions, if they were using this value. Otherwise, it won’t affect them.
A third approach is adding appropriate guards for this overflow behaviour, and perhaps having it be intended to be overflown, in which case you might need to manually provide this logic, if Java does not already provide such behaviour in a well-documented fashion. (I believe default behaviour is throw an exception)
Why is it necessary to store modification dates in this way in the region file? Can these dates be moved to the chunk data or removed entirely? If these dates were kept in the chunk data, these date stamps can be expanded to 64 bits because they are no longer constrained by a strict 4-byte size limit. If they are not used for anything, they could be removed entirely.
Is this still an issue in the latest version (1.20.4)?