Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121510
Message-ID: <77bce668-2f12-4a6e-826c-6b8997e52994@mabe.berlin>
Date: Sun, 29 Oct 2023 19:43:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: internals@lists.php.net
References: <fd8b7c1d-391b-4b7c-b331-ecd219834a82@mabe.berlin>
 <505DD7E0-A720-4357-A22F-2F7B42EEE9F3@sakiot.com>
 <ea5f3e6a-9aab-4c4a-8b3a-81a0d4695973@mabe.berlin>
In-Reply-To: <ea5f3e6a-9aab-4c4a-8b3a-81a0d4695973@mabe.berlin>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp
From: marc@mabe.berlin (Marc)


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 
>>> hand. Also JS uses a double float for timestamps in milliseconds 
>>> which is the most used lang together with PHP and there is tons of 
>>> code out there who does a simple */ 1000 to pass a date-time to/from 
>>> JS, which I wouldn't necessary decline.
>> I think there is no problem if it is up to milliseconds. This becomes 
>> a problem when it includes up to microseconds.
>>
>> 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:
>>
>> timestamp: 1698510347
>> => second: 2023-10-28 16:25:47(UTC)
>> => millisecond: 1970-01-20 15:48:30.347(UTC)
>>
> I'm not sure I fully understand what you mean.
>
> Obviously if you have a string to be parsed you need to use the 
> existing `createFromFormat`.
>
>>> One think that could be done is adding an optional second argument for
>>> allowing the microseconds part but again forcing PHP users to extract
>>> seconds and microseconds from a float isn't user friendly so I would
>>> still allow a float in the first place which than opens the question
>>> what to do if both arguments have fractions. Additionally this would
>>> break Carbons `createFromTimestamp($timestamp, $tz = null)`.
>>>
>>>
>>> Instead it would probably be better to add a `[get|set]Microseconds`
>>> method as well instead. I'm open for adding another PR for this.
>
> Just opened another PR for adding `[get|set]Microseconds` to support 
> handling seconds + microseconds as separate integers.
Missed the link: https://github.com/php/php-src/pull/12557
>
>> Regards.
>>
>> Saki
>
>
> Best,
> Marc
>