Re: New DateTime[Immutable]::createFromTimestamp

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]