On Mon, Jul 1, 2024, at 15:07, 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
Welcome back!

I think this is an interesting proposal and very useful. I think many people 
may be concerned about it being used in a non-testing context, but I don’t 
think we should stop people from being creative. If people find a use for it 
outside of testing, that would be interesting to see. The fact they can already 
do this today via carbon just makes a point that this is valuable to those of 
us who don’t like adding dependencies.

Ps. Anytime someone mentions PSR, have your favorite drink. It’ll help take the 
edge off. :) In all seriousness, PSR doesn’t apply universally and shouldn’t 
ever be a valid argument on this list. That’s my 2¢ anyway, best of luck to 
you. 

— Rob

Reply via email to