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) > 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. Right. There is no need to consider time zones for timestamps. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
