Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121496
Content-Type: multipart/alternative;
 boundary="------------02nWlk06kkjtIOuTP4Jjv1yB"
Message-ID: <fd8b7c1d-391b-4b7c-b331-ecd219834a82@mabe.berlin>
Date: Sat, 28 Oct 2023 18:09:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: internals@lists.php.net
References: <675b54f5-3fe5-4ecd-89dc-4c9dfc0cd77e@mabe.berlin>
 <D3CCEC5F-F86F-41C8-9DE5-D347071884AE@sakiot.com>
 <EFBF8E00-2AE8-4A08-B6F8-995E55A96609@gmail.com>
In-Reply-To: <EFBF8E00-2AE8-4A08-B6F8-995E55A96609@gmail.com>
Subject: Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp
From: marc@mabe.berlin (Marc)

--------------02nWlk06kkjtIOuTP4Jjv1yB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 28.10.23 17:33, Rowan Tommins wrote:
> On 28 October 2023 15:40:29 BST, Saki Takamachi<saki@sakiot.com>  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 code messy. It's then converted back to an integer internally, which isn't very efficient.
>
> I would be in favour of adding this method.

Thanks for your support :)

@saki, If you are dealing with unix timestamps you do (or should) handle 
these as numbers and being forced to to stringify these numbers only to 
parse it as numbers is error prone and not performant at all.

>> I have one concern. float is imprecise, so I don't think it's suitable for this kind of use. For timestamps, 16 digits are used, which exceeds the guaranteed precision of 15 digits on non-IBM platforms.
> 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 the past or future.https://www.wolframalpha.com/input?i=2**53+as+unix+timestamp
>
> Possibly you're thinking of a representation that counts integers as milliseconds or microseconds, instead of seconds?

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.

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.

PS: I didn't add a timezone argument here because a unix timestamp is in 
UTC by definition and changing the TZ is just one `setTimezone` call 
away not having to deal with any default/system/ini TZ setting.

> Regards,


Best,
Marc

--------------02nWlk06kkjtIOuTP4Jjv1yB--