On 29.10.23 19:41, Marc wrote:
Hi Saki,
On 28.10.23 18:32, Saki Takamachi wrote:
Hi Marc,
On a 64bit system it's obvious to have higher precision if you
handle the integer and fractions part separately (as timelib does)
but this doesn't help if you already have a floating point number at
Hi Saki,
On 28.10.23 18:32, Saki Takamachi wrote:
Hi Marc,
On a 64bit system it's obvious to have higher precision if you handle the
integer and fractions part separately (as timelib does) but this doesn't help
if you already have a floating point number at hand. Also JS uses a double
float
Hi, Rowan
I may have been thinking a little too much on the "technical side". Admittedly,
my concern is in rare cases.
OK, I understood that the problem is unlikely to occur in a realistic use case.
Now, I'll just quietly watch this discussion.
Regards.
Saki
--
PHP Internals - PHP Runtime Dev
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
Hi Marc,
> On a 64bit system it's obvious to have higher precision if you handle the
> integer and fractions part separately (as timelib does) but this doesn't help
> if you already have a floating point number at hand. Also JS uses a double
> float for timestamps in milliseconds which is the m
On 28.10.23 17:33, Rowan Tommins wrote:
On 28 October 2023 15:40:29 BST, Saki Takamachi wrote:
Hi Marc,
Personally, I don't think these are necessarily necessary since there is a "from
format".
As noted on the PR, both the default constructor and createFromFormat require
the input to be co
Hi Rowan,
> I'm not sure where you got those numbers; on a 64-bit architecture (surely
> the vast majority of PHP installs), a float can precisely represent any whole
> number from -2**53 up to 2**53 - 1. As a Unix timestamp, that's a one-second
> accuracy for any time 285 million years into th
On 28 October 2023 15:40:29 BST, Saki Takamachi wrote:
>Hi Marc,
>
>Personally, I don't think these are necessarily necessary since there is a
>"from format".
As noted on the PR, both the default constructor and createFromFormat require
the input to be converted to a string, which tends to make
Hi Marc,
Personally, I don't think these are necessarily necessary since there is a
"from format".
However, there is certainly an issue of convenience, so I'm not against it if
there's a demand for it.
I have one concern. float is imprecise, so I don't think it's suitable for this
kind of use
