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
