On 28.10.23 17:33, Rowan Tommins wrote:
On 28 October 2023 15:40:29 BST, Saki Takamachi<s...@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
