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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
