stopwatch query returns max_int when used for miliseconds after 24 days

The Bug

Due to command results being limited to integer, a stopwatch timer cannot be read once its internal value reaches the integer limit. Since it is stored internally as a long, it will still count up, and depending on scale value a useful value can still be read.

This means, the following precision cannot be read using commands after the amount of elapsed time:

• After 24d 20h 31m 23.648s miliseconds (it will always read like 24.20:31:23.647)

• After 248d 13h 13m 56.48s hundreths of a second (it will always read like 248.13:13:56.47)

• After approx. (using an average number of days per year) 6y 294d 1h 24m 12.8s tenths of seconds (always reads like 2485.01:24:12.7)

• After approx. 68y 18d 15h 28m 32s seconds (will always read like 24855.15:28:31)

I don’t think this should be a big issue for most usecases, and there was also no way to do this better previously using a world border. I am not sure whether this should count as a bug or a feature request.

Steps to Reproduce

• Either download the attached world ([mediaInline]), or download the [mediaInline] file and put it in your world’s data directory

• If not using the world file, run /scoreboard objectives add stopwatch dummy and /scoreboard objectives setdisplay sidebar stopwatch

• run /execute store result score $time_in_ms stopwatch run stopwatch query neun:long_running_timer 1000

Observed Result

The extracted time always reads 2147483647. This is btw also true when using execute store with a storage while storing a long or float, because the int conversion happens before.

Expected Result

There is some way to read the ms component without reading the entire value (e.g. /stopwatch <id> query ms returns (int) (value % 1000)).

Alternatively, it could just always do (int) (value % int.MAX), then you could still read the entire value and do some maths with the lower and higher bits, but this probably feels more buggy then the current behavior.