Add support for decimal values in relative time expressions

[khaledalam]

Description

This PR adds support for decimal values in relative time expressions (e.g., 2.5 weeks, 1.5 days, 3.14159 hours).

Fixes: php/php-src#21027

PR on php-src: php/php-src#21034

Problem

strtotime("2.37685 weeks") returned incorrect result (~414 million seconds instead of ~1.4 million) because:

• "2.37" matched timeshort24 pattern (hour:minute with dot separator)
• "685 weeks" was parsed as separate relative offset

Changes

• Added reldecimalnumber regex pattern for decimal numbers
• Added reldecimal lexer rule to match decimal relative expressions
• Added timelib_get_decimal_nr() helper to parse decimal values
• Added timelib_set_relative_decimal() to convert decimal units to seconds
• Added test cases for decimal relative time parsing

[derickr]

There are several issues with this patch:

• Although doing fractions of microseconds, seconds, minutes, and hours makes sense, you can't do the same for days, months, and years. Not every day, month, or year is the same length. 1.5 months can either be 42, 43.5, or 45 days. As all relative units should behave correctly depending on where they are applied to, I don't believe we should add this for these higher units.
• Right now, adding +1.4 seconds only adds 1 second to the field, and throws away the 400000 microseconds, as you cast these (line 848) with (timelib_sll) seconds. This is also a problem for very precise fractions for minutes and hours (1.43 minutes is 85 seconds and 800000 microseconds).

[hartman]

I'm also not sure if it is desirable to support decimal value interpretation. From the perspective of the ticket that I filed, I would also be happy with recognizing the decimal input and then throwing as 'not supported for the specified unit'.

The ticket is mostly concerned about how it is illogical that a decimal is cutoff at 2 places, gets an implicit unit assignment, and then the remainder of the string is suddenly a NEW secondary input, no longer a decimal and a number way bigger than the original intent of the writer of this input string.

This is a usability problem of the strtotime (and if we call that a bug or a feature, doesn't matter too much to me)