Fix #74940: DateTimeZone loose comparison always true #5227
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since `DateTimeZone` does not implement a `compare_objects` handler, nor has any properties, two `DateTimeZone` instances always compare as being equal, even if they designate totally different timezones. Even worse, after calling `var_dump()` on these objects, the actual comparison may yield a correct result. We therefore introduce a `compare_objects` handlers, which prevents different behavior before/after `var_dump()`, and which allows us to clearly define the intended semantics.
|
@derickr what do you think about this? |
derickr
reviewed
Mar 4, 2020
This is not supposed to happen, so actually checking at run-time is superfluous.
|
@derickr is this good to be merged? PHP-7.4 or master? |
|
Go for it, and IMO 7.4 is fine. |
|
Thanks! Applied as a2f8c78. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since
DateTimeZonedoes not implement acompare_objectshandler,nor has any properties, two
DateTimeZoneinstances always compare asbeing equal, even if they designate totally different timezones. Even
worse, after calling
var_dump()on these objects, the actualcomparison may yield a correct result.
We therefore introduce a
compare_objectshandlers, which preventsdifferent behavior before/after
var_dump(), and which allows us toclearly define the intended semantics.
Actually this is not something that should go into PHP-7.4 for BC reasons, but the current behavior is so wrong, that we might consider it nonetheless.
For now I implemented most basic comparison semantics, basically what happens right now after the objects have been var_dump()ed.