Re: New DateTime[Immutable]::createFromTimestamp

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