More robust parsing of large timespans (Fixes #2625)

[punchready]

Added a robust parsing method for positive timespans using an ulong. Commands that parse timespans now support up to 9999999 days. The old method must stay unmodified for compatibility, other plugins can upgrade manually if needed.

Fixes #2625

[JordanDi123]

Hey! Thanks so much for actioning this so quickly. 👍

[punchready]

Could probably update the existing TryParseTime(string, int) to call TryParseTime(string, long) and reduce code duplication, but I'm not overly fussed :)

the other method should stay to allow negative time spans imo, for whomever may need it.

[Arthri]

Also, I just noticed, I think a second method is unnecessary. You could fit 24855 days 3 hours 14 minutes and 7 seconds worth of seconds into the positive bounds of a 32-bit signed integer, casting the seconds to ulong before multiplying to turn it into milliseconds should be enough

[punchready]

The method still also ensures that the time span is positive, which is probably wanted in most cases. The issue in /tempgroup is already fixed by simply multiplying by 1000d which causes the seconds to be casted to double anyways (if my understanding is correct), considering that the timer class wants a double in any case.

[Arthri]

Looks good to me :+1:

[punchready]

Although now that i think of it, i forgot about some edge cases, like 1s-10d+11d...

[hakusaro]

@punchready

Although now that i think of it, i forgot about some edge cases, like 1s-10d+11d...

Were you planning on fixing those edge cases?

[punchready]

I don't think it's worth it since nobody is ever gonna enter time in that way (first creating a negative duration and then offsetting it to be positive again), and even if somebody does it, it will just be seen as invalid instead of breaking in weird ways.

[bartico6]

if you want to have it "1h shorter than 2 days" you'll input "1d23h" and not "2d-1h" lmao

I concur that it's pointless