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
