如何使Date-class在5.6.17和5.6.23上显示相同的结果

Question

First of all I'm aware of this question: PHP Date bug. It was finally resolved on PHP 5.6.23. So as I'm moving some of my severs from PHP 5.6.17 to PHP 5.6.23 I want the proper behavior on all of servers. But the project is huge, so to change all the Date-class usages with version check is a bit overhead, as it must be a temporary approach.

So the questions are:

• Is there a way to override Date-class on fly on symfony2 project with version check, so it could be the root point, which I could remove then?

• Could I somehow log unexpected behavior (some general decision, as there're a lot of usages as I said).

• If it's not possible, you are free to suggest something else.

Answer 1

As I see it you basically have three options. All have their drawbacks and advantages.

Monkey patching the function / method using uopz:

// first backup the original method
uopz_backup (\DateTime::class, 'methodToOverwrite');

// delete the original method
uopz_delete(\DateTime::class, 'methodToOverwrite');

// override the method
uopz_function(\DateTime::class, 'methodToOverwrite', function($arg) {
    // do customn stuff like check for versions and handling them differently here 
    if (version_compare(PHP_VERSION, '5.6.23', '<')) {
        // fix stuff
        return fixedstuff;
    }

    return default stuff;
});

// once you are done with your code restore the original method
uopz_restore (\DateTime::class, 'methodToOverwrite');

Pros:

• Don't have to change your code besides above
• Centralized place for the code

Cons:

• High wtfness level because the method does something else then what people expect
• You need to parse and properly handle whatever you are expecting in the method
• Relies in a non default extension
• Always have two paths to test in every instance

Going in an fixing every instance manually:

This would involve having version checks if statements all over your code.

Pros:

• It's clear what happens by just looking at the code

Cons:

• Having to find all occurrences
• Having (possibly) a lot of (the same) version checks if statements littered throughout your code
• People need to remember this

Abstract away the issue into a dedicated function / class:

It sounds like this thing that has the issue is something you are doing often. As such it would probably be better to abstract it away by putting it in a function / class.

Pros:

• Can easily be unit tested by just testing the function / class
• It hides the complexity and the version if statements
• Makes code's intent more clearer by having specific methods YourDate::getFirstTuesdayOfWeek()

Cons:

• Having to find all occurrences
• People need to remember this

Conclusion

Imo the last option is the best because it keeps your code clean, easy to extent and easy to test. And on top of that it has the lowest level of wtfness.