Re: Re: [Discussion] Add date_test_set_now() function
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
Thread (14 messages)