Add notification about DateTime and microseconds support #2186

SjonHortensius · 2016-11-05T14:23:52Z

The addition of microseconds to DateTime are great; but looking at the 3v4l.org bughunt output I see hundreds of scripts unexpectedly 'failing' because two variables are no longer equal due to non-obvious microsecond differences (eg. https://3v4l.org/7rdeS ).

Hopefully this notice will prevent some bogus bugreports

The addition of microseconds to DateTime are great; but looking at https://3v4l.org/bughunt/ I see hundreds of scripts unexpectedly 'failing' because two variables are no longer equal due to microsecond differences (eg. https://3v4l.org/7rdeS ). Hopefully this notice will prevent some bogus bugreports

Majkl578 · 2016-11-05T15:24:02Z

I commented on this issue below the commit here, noone seems to care unfortunately. I'm going to properly report it as a bug (BC break) in RC.

SjonHortensius · 2016-11-05T15:33:10Z

I agree, see my related comment @ https://bugs.php.net/bug.php?id=73301. This change should have been added to 7.1.0 from the start; or moved to 7.2.

It seems some PHP developers handle a different definition then what is generally accepted:

A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release.

I find it intriguing this specific change was added by @derickr who is normally very vocal against any change that creates BC behaviour (see various RFC votes)

Majkl578 · 2016-11-05T15:42:55Z

Hmm, nice catch with setTime BC break, it definitely breaks subclasses (and is not even documented). 😟
https://3v4l.org/Kmogl
Whole microseconds patch should be reverted and moved to 7.2 imho.

ccing RMs again: @dshafik @krakjoe

derickr · 2016-11-05T15:53:42Z

I asked @dshafik before merging this large amount if bug fixes.
There is no BC break in any stable released versions.
Asking for this to be reverted means bug fixes don't make it out for another year.
Bugs can always be fixed regardless of whether we're in RC or not, even in patch releases.

derickr · 2016-11-05T15:55:30Z

UPGRADING

@@ -280,6 +280,9 @@ PHP 7.1 UPGRADE NOTES
  . Timezone initialization failure from serialized data will now throw an
    instance of Error from __wakeup() or __set_state() instead of resulting in
    a fatal error.
+  . DateTime instances now support microseconds. Please note this can have impact
+    when comparing; eg. this would previously return TRUE, but now returns FALSE:
+     (new DateTime('first day of next month') == new DateTime('first day of next month'));


This is not a new change. This could result in false before if the first and second instantiation spanned a change in current second.

True, but if generating a DateTime takes roughly 4 μs (which it does for me), this happens ~ 250.000 times more often

True, but if generating a DateTime takes roughly 4 μs (which it does for me), this happens ~ 250.000 times more often

That doesn't make that the developer's original assumption was correct. There was still a bug in their code.

People not understanding an issue should not prevent fixing bugs. It's in the same league as not knowing about DST and assuming that each day is 86400 seconds long.

I will add something to UPGRADING, but with a better wording, so will be closing this PR.

It is definitely a gotcha for faulty code that happened to work most of the times. The good thing is the bug will surface more often and get fixed!

Note in UPGRADING for 7.1 has been added with 69a3659

Majkl578 · 2016-11-05T16:01:25Z

There is no BC break in any stable released versions.

Isn't there really? How about these?
https://3v4l.org/Kmogl
https://3v4l.org/4Z0et

another multiple issues with ==, >=, <= etc.

Don't they look like a BC break? They do, at least to me. The behavior obviously changed.

Asking for this to be reverted means bug fixes don't make it out for another year.

That is perfectly ok if they break BC, some of them actually look rather like feature requests...

Bugs can always be fixed regardless of whether we're in RC or not, even in patch releases.

Not if they break BC with stable versions. This makes any semver promises/expectations void.

arjenschol · 2016-11-07T10:42:57Z

There is no easy way to set microseconds to 0, you have to call setTime see https://3v4l.org/YUhFF A setMicroseconds method would be handy and/or support to relative strings to set microseconds to 0 (just like midnight does for H:i:s). Or am I missing something?
Microsecond support is useful, by not by default I think. Why not introduce a 3rd parameter $with_microseconds/$set_microseconds which defaults to false? Or A second class DateTimeWithMicroseconds? Maybe not so fancy naming, but it's very clear what will happen.
The 4th parameter to setTime() should not cause BC breakage.

dshafik · 2016-11-07T11:10:13Z

I concur with @arjenschol here, particularly on the BC breaks.

I think default microseconds to 0 when unspecific for relative strings is correct behavior
Preserving BC is critical, however introducing a new class also means a new immutable variant too. I'd be more in favor of an argument, but that's up to @derickr
Agreed. Add a new method, maybe setMTime()? Having said this, examples of this type of usage are minimal on GitHub.

jerrygrey · 2016-11-07T11:15:40Z

Defaulting microseconds to zero, like seconds, should avoid this BC break and avoid the need for new classes and methods. But keep in mind, the final release of 7.1 is due in a few weeks and if this can't be fixed quickly, it should be reverted so that it doesn't be delayed 7.1

derickr · 2016-11-07T15:57:53Z

UPGRADING

@@ -280,6 +280,9 @@ PHP 7.1 UPGRADE NOTES
  . Timezone initialization failure from serialized data will now throw an
    instance of Error from __wakeup() or __set_state() instead of resulting in
    a fatal error.
+  . DateTime instances now support microseconds. Please note this can have impact
+    when comparing; eg. this would previously return TRUE, but now returns FALSE:
+     (new DateTime('first day of next month') == new DateTime('first day of next month'));


True, but if generating a DateTime takes roughly 4 μs (which it does for me), this happens ~ 250.000 times more often

That doesn't make that the developer's original assumption was correct. There was still a bug in their code.

People not understanding an issue should not prevent fixing bugs. It's in the same league as not knowing about DST and assuming that each day is 86400 seconds long.

I will add something to UPGRADING, but with a better wording, so will be closing this PR.

dshafik · 2016-11-07T19:48:39Z

@derickr

the change to the signature of setTime() is a valid concern that needs to be addressed.
We should document that the correct way to get the relative date, should be something like: new DateTime('midnight first day of next month') (because adding midnight makes it not depend on current time)
I support a third argument to toggle microseconds (off by default)

7.1.0RC6 is being built tomorrow or the next day, as the last RC, I'd like to see this resolved before then or we will have to revert. True bug fixes can be done in 7.1.1 and beyond.

derickr · 2016-11-07T20:14:08Z

This pull request is unrelated to that dicussion.

SjonHortensius · 2016-11-08T10:44:23Z

FWIW; 69a3659

derickr reviewed Nov 5, 2016

View reviewed changes

smalyshev added the Quickfix label Nov 6, 2016

derickr requested changes Nov 7, 2016

View reviewed changes

derickr closed this Nov 7, 2016

Add notification about DateTime and microseconds support #2186

Add notification about DateTime and microseconds support #2186

Uh oh!

Conversation

SjonHortensius commented Nov 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Majkl578 commented Nov 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SjonHortensius commented Nov 5, 2016

Uh oh!

Majkl578 commented Nov 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

derickr commented Nov 5, 2016

Uh oh!

derickr Nov 5, 2016

Choose a reason for hiding this comment

Uh oh!

SjonHortensius Nov 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

derickr Nov 7, 2016

Choose a reason for hiding this comment

Uh oh!

hashar Jan 28, 2017

Choose a reason for hiding this comment

Uh oh!

Majkl578 commented Nov 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arjenschol commented Nov 7, 2016

Uh oh!

dshafik commented Nov 7, 2016

Uh oh!

jerrygrey commented Nov 7, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

derickr Nov 7, 2016

Choose a reason for hiding this comment

Uh oh!

dshafik commented Nov 7, 2016

Uh oh!

derickr commented Nov 7, 2016

Uh oh!

SjonHortensius commented Nov 8, 2016

Uh oh!

Uh oh!

SjonHortensius commented Nov 5, 2016 •

edited

Loading

Majkl578 commented Nov 5, 2016 •

edited

Loading

Majkl578 commented Nov 5, 2016 •

edited

Loading

SjonHortensius Nov 5, 2016 •

edited

Loading

Majkl578 commented Nov 5, 2016 •

edited

Loading

jerrygrey commented Nov 7, 2016 •

edited

Loading