Re: New DateTime[Immutable]::createFromTimestamp

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