Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124148
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <b7589018-75b1-44b6-b819-5bcaa47a3be9@app.fastmail.com>
In-Reply-To: 
 <CABTDVhB1WKKAky6y72mTqAJLKP1ZgwwrjYePsg+VAJuA4Fp6pg@mail.gmail.com>
References: 
 <CABTDVhAXLuiKtbz4P_jwhHe=h_r62037mRE2Eg-864DoweOahw@mail.gmail.com>
 <CABTDVhB1WKKAky6y72mTqAJLKP1ZgwwrjYePsg+VAJuA4Fp6pg@mail.gmail.com>
Date: Mon, 01 Jul 2024 16:40:19 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function
Content-Type: text/plain
From: larry@garfieldtech.com ("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 reasons:
>
> 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-time instance of the Clock.

--Larry Garfield