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)
Quinn
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)