On 28/10/2023 16:47, Saki Takamachi wrote:
> Yes, I'm assuming a timestamp that includes up to microseconds. This
> is because in the last example of the PR description, the microsecond
> timestamp was expressed as a float.
Floating point numbers don't suddenly become unpredictable after a
certain point, nor is there a strict relationship with any number of
decimal digits. Rather, their absolute precision varies based on their
magnitude - for each power of 2 in magnitude, they lose a power of 2 in
absolute precision.
More specifically, an IEEE float64 / double precision has 53 significant
bits, which can be allocated to either the whole or fractional part of a
number. It has a precision of at least 1 up to 2**53-1, at least 0.5 up
to 2**52-1, and so on - a precision of 1/2**(53-n) for values up to (2**n)-1
Plugging that formula into a spreadsheet, I get:
* accuracy to nearest microsecond up to the year 2242 (1/2**20 up to
2**33-1 seconds)
* accuracy to nearest 10 microseconds up to the year 4147 (1/2**17 up to
2**36-1 seconds)
* accuracy to nearest millisecond up to the year 280701 (1/2**10 up to
2**43-1 seconds)
An application that needs to represent a timestamp more than 200 years
in the future, with a precision of 1 microsecond, is going to be very rare.
> Another problem is that there are "millisecond" and "microsecond" timestamp formats that do not include dots, how should they be handled? In reality, such a use case is unlikely, but it is virtually impossible to tell the difference between the two
Distinguishing between the two is up to the user, just as it is up to
the user to feed the right format to createFromFormat(). If they know
they have a number of microseconds, they could use
DateTimeImmutable::createFromTimestamp($value / 1_000_000) - as
discussed above, this will not lose any accuracy for dates in the next
200 years or so.
Regards,
--
Rowan Tommins
[IMSoP]
