Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121509
Content-Type: multipart/alternative;
 boundary="------------00dkwwygflMGxQ5vWvaP5RNm"
Message-ID: <ea5f3e6a-9aab-4c4a-8b3a-81a0d4695973@mabe.berlin>
Date: Sun, 29 Oct 2023 19:41:37 +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>
In-Reply-To: <505DD7E0-A720-4357-A22F-2F7B42EEE9F3@sakiot.com>
Subject: Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp
From: marc@mabe.berlin (Marc)

--------------00dkwwygflMGxQ5vWvaP5RNm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

> Regards.
>
> Saki


Best,
Marc

--------------00dkwwygflMGxQ5vWvaP5RNm--