On Mon, Jul 1, 2024, at 1:07 PM, Go Kudo wrote:
> 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

We don't generally add features just to support very-old legacy code.  These 
days, the correct answer would be to use PSR-20.  (Implementations are 
trivially easy, many available, and it's dead easy to write your own.)  That 
doesn't much help legacy code, but adding global features just to support 
legacy code that should get refactored anyway doesn't seem like a great idea.

--Larry Garfield

Reply via email to