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年7月2日(火) 1:41 Larry Garfield <la...@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 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 >
