Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124169 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 3F5BD1A009C for ; Mon, 1 Jul 2024 23:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719878342; bh=SBDXCZkfc7EiNj+oc+uOLHjIMOP6Qidqonp6YgQ/3k8=; h=References:In-Reply-To:From:Date:Subject:To:From; b=BrBNnomhQGJrU0iSU3msK/n0SnObAuxPKDK/FyykxwSuLa0b95MELXI+q+lKZS4/g A+vuI3UIMrslv//mc6rePzKl6Lt208IAbPhdB80rdFrpDrU+ITWZ4rP/D4VwHZnN0B 74Sh//gwPTONbnvsbWqmTA6X31c+vTn6wHT86Zw2J4urggbo8rh4m1e/1swKYwebfI Ikoo0SAQSeEypgOrGA5hVC3sHMoowwLKN6x9Sf//IS49hhK3Jj6EthN4s3dug69EuZ 5p74V/aHEXyXDs6Uv35QnptFdOFIKISyDRFDKW/DpEDV8uO8R5xmBGKULRJGtKU1/3 DMrTDmZt2MtkQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 038B1180576 for ; Mon, 1 Jul 2024 23:59:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jul 2024 23:59:00 +0000 (UTC) Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-79c0c19ff02so286721385a.1 for ; Mon, 01 Jul 2024 16:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719878259; x=1720483059; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=a313d9yUAcjM5yHBECDQH499WvUGRNG8/OiXDG0/r7s=; b=b1G5A+8lWptyVJQw70C4RC+nZYD5MVzLM/pembuSwOy1Gx8U79NxgoGcKrtVDmF4uV QeHXqvIJ2s3DD6jLJSHiw0LgD7G1jbspHgTlr2N09IkZgxlEm/fzkI5NUwXZH2u+H4DX KsCfx0dJUfgXDYuN3w6DPfYrIqmj+sdy6ABCIbLg4GCqrMdsdQ3mny0Bysd6SQ3I0Il3 cq7qhtcUjtXSoZhouZR+L6EeEeRpU43KBIXOboA8G6Hc7ImvVoDtGQMkErTB7AoWrlpH x0NezuotdbEkcJImGKuELXdeWEto2KPT3EgxVuYMk3jrYqcg5lS5UkUGEdCjXYb+BbMs l2ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719878259; x=1720483059; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a313d9yUAcjM5yHBECDQH499WvUGRNG8/OiXDG0/r7s=; b=YppuHd0nsYcJW/x3lMJzeLL6vTq74Tafd4W47GhBnYORq+QDykzJaZylPr5EakKks4 QsiBFM2FcqHaNmCC2YhdQSw8vsjodeBfb6SkBvBqcwpwqrQ8F42y4Ojda1cvu+Qa6FKA IgylDRhJPTAWWi8aTjgYK8hWHXo1N+vcw21sIlcLn6GSge9+33ecVJ7/Ko0HPQKEJVM4 Ow229MMq5rYIXlmTaIVnqTNwy5ps/yxiB6lwKMsyd7bO5kkbv6g7vRfkGRDWgpv5lzCp smRjLeyznEnGSTOxLDZGxw90eYJASbAr+XCCP6+tzhVPBcAcVGp8nSAvwoR0xik2iXBG DG5A== X-Gm-Message-State: AOJu0YwasIdasAGLVAuZWrbRCpSF95c0RNvn0ZHXvWYZjNHMBEPZ2SEk XDrfF/vMuXWmQHvmVnJyEBs463XbmgcQR0QcZYg9aUWFby4wc1VCqnVyjceSHeqjQQWRiqhNJ1H lPOu+nRw8p0RsZGaEJ5b/8xj12VydvfVb X-Google-Smtp-Source: AGHT+IFXLV+lr5KuKNDV3TxePcLQxESr2B3uw9LTkk8dn/e0VQOaxDpsysfojIt8UfiKBjJ8ISk07cGyNUC4L5rzBz0= X-Received: by 2002:a05:620a:4e9:b0:79d:5b21:804b with SMTP id af79cd13be357-79d7ba89238mr699237385a.63.1719878258620; Mon, 01 Jul 2024 16:57:38 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 2 Jul 2024 08:57:27 +0900 Message-ID: Subject: Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function To: PHP internals , Larry Garfield Content-Type: multipart/alternative; boundary="000000000000a9829e061c385cca" From: zeriyoshi@gmail.com (Go Kudo) --000000000000a9829e061c385cca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi. > So don't do that. Relying on global mutable state is a bug. That older parts of the stdlib made that mistake doesn't mean we should continue it. (See also the Random extension, which also works to avoid global mutable state.) I generally agree. However, I have some questions. It's true that relying on global state is generally undesirable. I dislike stateful approaches so much that I proposed and implemented ext-random in PHP 8.2. However, the concept of date and time is stateful in the real world we live in. For example, time varies due to various factors such as time zones and daylight saving time. Even now, if you execute `date_default_timezone_set()`, the current time can potentially rewind. https://3v4l.org/FJn4e This behavior completely depends on the internal state of ext-date, but I don't think it should be abolished because changing the time zone to consider during execution is also a realistic scenario. Similarly, I don't think the proposed `date_test_set_now()` will create new flaws. There's also the issue of convenience. It's possible to take an approach similar to ext-random for ext-date, but that would result in a significant increase in the amount of code to write. Additionally, there's the problem that the current `\DateTimeInterface` doesn't cover all the functionality provided by ext-date functions, making a drop-in replacement impossible. (ext-random is completely replaceable) As an aside, I once proposed deprecating the `mt_rand()`, `mt_srand()`, `rand()`, and `srand()` functions. However, it was rejected on the grounds that it was unnecessary and excessive for many workloads. Couldn't the same be said for this case? https://wiki.php.net/rfc/deprecations_php_8_3 I look forward to your reply. Best Regards Go Kudo 2024=E5=B9=B47=E6=9C=882=E6=97=A5(=E7=81=AB) 1:41 Larry Garfield : > On Mon, Jul 1, 2024, at 3:56 PM, Go Kudo wrote: > > > I apologize, the main point of my explanation was off. > > > > To put it simply, I'm suggesting that it might be good to implement > > convenient and commonly used features from Carbon at the ext-date level= . > > > > I'm proposing the date_test_set_now() function for the following reason= s: > > > > User-land libraries like Carbon / Chronos have a setTestNow method, > > indicating a potential demand for this feature. > > It's impossible to determine whether a value is relative or absolute > > time from either user-land or Extension. > > While this is convenient for maintaining legacy systems, that's not the > > essence of this proposal. > > > > As you pointed out, this is an issue that should ideally be solved in > > user-land. I deeply understand that. > > > > However, in reality, PHP's time-related processing is diverse, and to > > comprehensively handle all of these, it seems necessary to address this > > at the ext-date level. > > > > https://www.php.net/manual/en/ref.datetime.php > > > > For example, you might want to use the date() function to display the > > current time on a whim. However, doing this ruins everything. > > > > Even if other parts of your code use Carbon or comply with PSR-20, > > using the date() function is problematic because the current time it > > references cannot be modified. > > > > `date_test_now(\DateInterval $shiftInterval)` can solve this problem. > > > > Of course, there might be various side effects. However, seeing > > `Carbon::setTestNow()` being used in various places, I think this > > feature might be necessary. > > > > I would appreciate your thoughts on this. > > > > Best Regards, > > Go Kudo > > They are unchanged. > > > For example, you might want to use the date() function to display the > > current time on a whim. > > So don't do that. Relying on global mutable state is a bug. That older > parts of the stdlib made that mistake doesn't mean we should continue it. > (See also the Random extension, which also works to avoid global mutable > state.) > > > Of course, there might be various side effects. > > Exactly. This is not something to just brush aside with a comment. > > The way Carbon does it is wrong, for the same reason: It just sets a > global state. The correct answer is to use PSR-20 and inject a fixed-tim= e > instance of the Clock. > > --Larry Garfield > --000000000000a9829e061c385cca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.

> So don't do that.=C2=A0 Relying on glo= bal mutable state is a bug.=C2=A0 That older parts of the stdlib made that = mistake doesn't mean we should continue it. =C2=A0(See also the Random = extension, which also works to avoid global mutable state.)

I genera= lly agree. However, I have some questions.

It's true that relyin= g on global state is generally undesirable. I dislike stateful approaches s= o much that I proposed and implemented ext-random in PHP 8.2.

Howeve= r, the concept of date and time is stateful in the real world we live in. F= or example, time varies due to various factors such as time zones and dayli= ght saving time.
Even now, if you execute `date_default_timezone_set()`,= the current time can potentially rewind.

https://3v4l.org/FJn4e

This behavior completely depends= on the internal state of ext-date, but I don't think it should be abol= ished because changing the time zone to consider during execution is also a= realistic scenario.
Similarly, I don't think the proposed `date_tes= t_set_now()` will create new flaws.

There's also the issue of co= nvenience. It's possible to take an approach similar to ext-random for = ext-date, but that would result in a significant increase in the amount of = code to write.
Additionally, there's the problem that the current `\= DateTimeInterface` doesn't cover all the functionality provided by ext-= date functions, making a drop-in replacement impossible. (ext-random is com= pletely replaceable)

As an aside, I once proposed deprecating the `m= t_rand()`, `mt_srand()`, `rand()`, and `srand()` functions.
However, it = was rejected on the grounds that it was unnecessary and excessive for many = workloads. Couldn't the same be said for this case?

https://wiki.php.net/rfc/depr= ecations_php_8_3

I look forward to your reply.

Best Regards
Go Kudo

2024=E5=B9=B47=E6=9C=882=E6=97=A5= (=E7=81=AB) 1:41 Larry Garfield <larry@garfieldtech.com>:
On Mon, Jul 1, 2024, at 3:56 PM, Go Kudo wrote:

> I apologize, the main point of my explanation was off.
>
> To put it simply, I'm suggesting that it might be good to implemen= t
> convenient and commonly used features from Carbon at the ext-date leve= l.
>
> I'm proposing the date_test_set_now() function for the following r= easons:
>
> User-land libraries like Carbon / Chronos have a setTestNow method, > indicating a potential demand for this feature.
> It's impossible to determine whether a value is relative or absolu= te
> time from either user-land or Extension.
> While this is convenient for maintaining legacy systems, that's no= t the
> essence of this proposal.
>
> As you pointed out, this is an issue that should ideally be solved in =
> user-land. I deeply understand that.
>
> However, in reality, PHP's time-related processing is diverse, and= to
> comprehensively handle all of these, it seems necessary to address thi= s
> at the ext-date level.
>
> https://www.php.net/manual/en/ref.datetime.php
>
> For example, you might want to use the date() function to display the =
> current time on a whim. However, doing this ruins everything.
>
> Even if other parts of your code use Carbon or comply with PSR-20, > using the date() function is problematic because the current time it <= br> > references cannot be modified.
>
> `date_test_now(\DateInterval $shiftInterval)` can solve this problem.<= br> >
> Of course, there might be various side effects. However, seeing
> `Carbon::setTestNow()` being used in various places, I think this
> feature might be necessary.
>
> I would appreciate your thoughts on this.
>
> Best Regards,
> Go Kudo

They are unchanged.=C2=A0

> For example, you might want to use the date() function to display the =
> current time on a whim.

So don't do that.=C2=A0 Relying on global mutable state is a bug.=C2=A0= That older parts of the stdlib made that mistake doesn't mean we shoul= d continue it.=C2=A0 (See also the Random extension, which also works to av= oid global mutable state.)

> Of course, there might be various side effects.

Exactly.=C2=A0 This is not something to just brush aside with a comment.=C2= =A0

The way Carbon does it is wrong, for the same reason: It just sets a global= state.=C2=A0 The correct answer is to use PSR-20 and inject a fixed-time i= nstance of the Clock.

--Larry Garfield
--000000000000a9829e061c385cca--