Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121497
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Sun, 29 Oct 2023 01:32:05 +0900
Message-ID: <505DD7E0-A720-4357-A22F-2F7B42EEE9F3@sakiot.com>
References: <fd8b7c1d-391b-4b7c-b331-ecd219834a82@mabe.berlin>
Cc: internals@lists.php.net
In-Reply-To: <fd8b7c1d-391b-4b7c-b331-ecd219834a82@mabe.berlin>
To: Marc <marc@mabe.berlin>
Subject: Re: [PHP-DEV] New DateTime[Immutable]::createFromTimestamp
From: saki@sakiot.com (Saki Takamachi)

Hi Marc,

> On a 64bit system it's obvious to have higher precision if you handle the i=
nteger 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 f=
loat for timestamps in milliseconds which is the most used lang together wit=
h 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 prob=
lem when it includes up to microseconds.

Another problem is that there are "millisecond" and "microsecond" timestamp f=
ormats that do not include dots, how should they be handled? In reality, suc=
h a use case is unlikely, but it is virtually impossible to tell the differe=
nce between the two:=20

timestamp: 1698510347
=3D> second: 2023-10-28 16:25:47(UTC)
=3D> millisecond: 1970-01-20 15:48:30.347(UTC)

> PS: I didn't add a timezone argument here because a unix timestamp is in U=
TC 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=