2024年7月1日(月) 22:07 Go Kudo <zeriyo...@gmail.com>: > Hi, Internals. > > I've been absent for a long time due to poor health. I'm finally back. > > I maintain a legacy application written in PHP, and occasionally need to > fake the current time for testing purposes. However, PHP doesn't provide a > standard way to fake the current time, so I've been changing the OS's > current time to do this, which is quite painful. > > This can be avoided by using third-party libraries (such as > Carbon::setTestNow()). However, it's almost impossible to modify all parts > of a legacy application that depend on the current time. > > Another option is to use libfaketime ( > https://github.com/wolfcw/libfaketime), but this is also quite painful to > use. > > Since this was absolutely necessary for my work, I implemented this > functionality as a PHP Extension. (Please ignore the dirty implementation > related to PDO. I'm not planning to propose it this time.) > > https://github.com/colopl/php-colopl_timeshifter > > However, this Extension has some problems. > > The first is that there's no way to determine whether the format passed to > the ext-date parser is relative or absolute time, resulting in a dirty hack > using usleep. The second is that it depends on timelib, so it breaks when > upstream changes related to timelib are made. > > So, how about adding a `date_set_test_now(\DateInterval $shiftInterval)` > function to ext-date? > > This function would treat the current time as shifted by the passed > DateInterval. Since it's implemented on the ext-date side, there's no need > for dirty hacks using usleep. > > I'd like to hear your opinions. Thank you. > > Best Regards, > Go Kudo >
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
