Fixed issue #883 #884

Ovsyanka · 2017-02-03T00:19:34Z

No description provided.

lucasmichot · 2017-02-03T11:44:14Z

Very nice @Ovsyanka - let me have a look at it later

Ovsyanka · 2017-02-03T12:46:07Z

It also should fix #887, #863, #871

lucasmichot

Some small changes, but looks good !

lucasmichot · 2017-02-05T21:04:58Z

src/Carbon/Carbon.php

-        if ($this->local) {
-            return parent::modify($modify);
-        }
+        $shouldBeModifiedInUtc = preg_match('/(sec|second|min|minute|hour)s?/', $modify);


Is a variable really useful here?

lucasmichot · 2017-02-05T21:05:29Z

tests/Carbon/ModifyTest.php

+
+    /**
+     * @dataProvider getDealWithDayLightTests
+     */


@param docblocks missing :-(

lucasmichot · 2017-02-05T21:06:07Z

tests/Carbon/ModifyTest.php

+        $date = new Carbon($dateString, $timezone);
+        $date->modify($modify);
+        $this->assertSame($expected, $date->format('Y-m-d H:i:s P'));
+        $this->assertInstanceOf('Carbon\Carbon', $date);


Feel free to use assertInstanceOfCarbon

lucasmichot · 2017-02-05T21:07:16Z

src/Carbon/Carbon.php

-        $instance = parent::modify($modify);
-        $this->setTimezone($timezone);
+        if ($shouldBeModifiedInUtc) {
+            $timezone = $this->getTimezone();


Maybe use a negated assertion and an early return here ?

Ovsyanka · 2017-02-05T21:28:09Z

Okay! I will make done it very soon.
The first two remarks are more about code style. But i think it is not a question to discuss, so i will change in the way you suggested.
The last two very reasonable, i will fix it too.

lucasmichot · 2017-02-05T21:29:21Z

👍

Ovsyanka · 2017-02-05T21:29:36Z

Oh, i need to clarify - how i have to handle it. Should i make another commit in that branch or just make another pull-request? it is my first real pull-request =)

lucasmichot · 2017-02-05T21:32:05Z

I wish all your next PRs could be as good as your first one then 👌! You can simply add another commit to thir PR Le dim. 5 févr. 2017 à 22:29, Igor <notifications@github.com> a écrit :

…

Oh, i need to clarify - how i have to handle it. Should i make another commit in that branch or just make another pull-request? *it is my first real pull-request =)* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#884 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfWQ_2RMpeZ6reoqIGNbObPtA0RPSvdks5rZj9BgaJpZM4L10AV> .

Ovsyanka · 2017-02-05T21:44:59Z

Actially i changed my mind a little, about early return. I think it is not good in this case. I think that it is fine to handle errors, when you just stopping the function and do not doing it's main task. But if you doing useful tasks in different manner, i surely suppose, that you have to use if-else block. It is more clearly to understand.
Do you agree with me? May i let it in that manner?

lucasmichot · 2017-02-06T22:10:04Z

Sure @Ovsyanka

Ovsyanka · 2017-02-07T08:29:27Z

Okay, i already did this in the last commit before your commentю It contains all changes i supposed to do.

kaufholdr · 2017-02-07T08:52:11Z

First of all I like this fix.

In my opinion it would be nice to have a small extension in the documentation of modify about when DST is included and when it is ignored.

hinovana · 2017-02-13T07:21:26Z

src/Carbon/Carbon.php

+        // If we changing time in some timezone with daylight correction, there can be the case,
+        // that this correction influence to time in nonwanted way.
+        // So we have to make this modification in UTC timezone.
+        if (!preg_match('/(sec|second|min|minute|hour)s?/', $modify)) {


case-insensitive search ?

Great suggestion! I will fix it.

Ovsyanka · 2017-02-13T08:48:51Z

I rebased branch to actual master and made regexp case-insensitive.

lucasmichot · 2017-02-13T09:23:03Z

Just restarting Travis

Ovsyanka · 2017-02-13T11:33:45Z

@kaufholdr wrote:

In my opinion it would be nice to have a small extension in the documentation of modify about when DST is included and when it is ignored.

I totally agree with you, but i think it should be in another issue (and pull-request) because that is not nesessary to apply this pull-request. And i dont know where to place such documentstion.

I think there is appropriate existed issue #890

Ovsyanka · 2017-02-16T23:28:14Z

@lucasmichot, why you do not merging this pull-request? Should i do something else?

bensinclair · 2017-04-05T23:29:44Z

Would love to see this merged. We are experiencing the same issue and have had to create workarounds.

oceanwap · 2017-06-06T12:22:42Z

Is anyone going to merge this? It's pending for so long.

vlakoff · 2017-10-16T07:45:42Z

Ouch, I just got notified of this issue too. Looks like this PR deserves a bump :)

vlakoff · 2017-10-16T07:51:25Z

src/Carbon/Carbon.php

+        // If we changing time in some timezone with daylight correction, there can be the case,
+        // that this correction influence to time in nonwanted way.
+        // So we have to make this modification in UTC timezone.
+        if (!preg_match('/(sec|second|min|minute|hour)s?/i', $modify)) {


Technically, this regex is equivalent to /sec|min|hour/i

Also, what is the situation concerning the other modifiers ("day", "week", etc.)?

Technically - yes, but this is more explicit and obvious for human reading. I will move the long regexp into comments and replace it by short one in the code.

Others is OK. Modifications by units bigger than hour leaves time of the day non changed.
You could add some tests for that, btw.
Hm, actually the pull-request have some tests for this already (day unit).

I had to dig a bit to find this documentation page: Relative Formats.

I realised that sec matches to "ordinal" second (like first, second, third). But it must not. I am not sure about how to solve this. I have to think about that.

I suppose to make something like this: /[+-]?[0-9]+ (sec|min|hour)\w*( ago)?/i.
The idea is: the unit tokens goes only with numbers behind it and|or ago after.
What do you think?

Upd: hmmm. I see potential problems. It could be

second hour of <some date> (I have to investigate if it is a problem)

10 hours (If it just set the time of a day this shouldn't be "fixed")

@vlakoff, Look at #883 (comment) plz.

All relative modifications, except seconds, minutes and hours was broken because modifications was forced processed in UTC timezone. Now only seconds, minutes and hours modifications processing in UTC. For example i have the date 2014-03-30 00:00:00 in Europe/London (new Carbon('2014-03-30 00:00:00, 'Europe/London')), then if i want to increase date by 1 day, i expect 2014-03-31 00:00:00, but if want to increase date by 24 hours, then i expect 2014-03-31 01:00:00, because in this timezone there will be that time after 24 hours (timezone offset changes because of Daylight correction). The same for minutes and seconds.

lwille · 2018-01-11T11:41:36Z

Any news?

Ovsyanka · 2018-01-11T11:44:34Z

I am waiting for votes on my comment #883 (comment). I am not using Carbon by myself, so I don't want to do some work that I am not sure will be needed.

Ovsyanka · 2018-01-15T18:12:13Z

I decide to rid off this pull-request because that is wrong approach to solve the problem. Look at the #883 (comment) for details.

lucasmichot reviewed Feb 5, 2017

View reviewed changes

lucasmichot added 1.x bug labels Feb 5, 2017

This was referenced Feb 6, 2017

Carbon does not handle DST correct when calculating in users default timezone. #887

Closed

Timezone offset is added to the value after upgrading to 1.22 #863

Closed

Issue with addSeconds and RFC dates after upgrade to 1.22.1 #871

Closed

Ovsyanka force-pushed the issue-883 branch 2 times, most recently from 88d3bd5 to 0d94cc9 Compare February 9, 2017 17:37

hinovana reviewed Feb 13, 2017

View reviewed changes

Ovsyanka force-pushed the issue-883 branch from 0d94cc9 to 638eb4e Compare February 13, 2017 08:46

lucasmichot closed this Feb 13, 2017

lucasmichot reopened this Feb 13, 2017

Ovsyanka mentioned this pull request Feb 16, 2017

addWeekDays() not working as expected with non-UTC timezone #896

Closed

This was referenced Mar 10, 2017

Next seems to return incorrect values when not using UTC #909

Closed

Wrong day returned when using subDay() daylight saving time to standard time. #911

Closed

Corrects improper handling of daylight savings time #912

Closed

This was referenced Apr 1, 2017

Confusing addMonth(s) method #915

Closed

modify() method resets timezones to UTC, causes issues #930

Closed

vlakoff reviewed Oct 16, 2017

View reviewed changes

Ovsyanka force-pushed the issue-883 branch from 638eb4e to d27512a Compare October 16, 2017 08:40

Ovsyanka mentioned this pull request Oct 26, 2017

DST handling while date modifying cakephp/chronos#135

Closed

Ovsyanka closed this Jan 15, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixed issue #883 #884

Fixed issue #883 #884

Ovsyanka commented Feb 3, 2017

lucasmichot commented Feb 3, 2017

Ovsyanka commented Feb 3, 2017

lucasmichot left a comment

lucasmichot Feb 5, 2017

lucasmichot Feb 5, 2017

lucasmichot Feb 5, 2017

lucasmichot Feb 5, 2017

Ovsyanka commented Feb 5, 2017

lucasmichot commented Feb 5, 2017

Ovsyanka commented Feb 5, 2017

lucasmichot commented Feb 5, 2017 via email

Ovsyanka commented Feb 5, 2017 •

edited

Loading

lucasmichot commented Feb 6, 2017

Ovsyanka commented Feb 7, 2017 •

edited

Loading

kaufholdr commented Feb 7, 2017

hinovana Feb 13, 2017

Ovsyanka Feb 13, 2017

Ovsyanka commented Feb 13, 2017

lucasmichot commented Feb 13, 2017

Ovsyanka commented Feb 13, 2017 •

edited

Loading

Ovsyanka commented Feb 16, 2017

bensinclair commented Apr 5, 2017

oceanwap commented Jun 6, 2017

vlakoff commented Oct 16, 2017

vlakoff Oct 16, 2017 •

edited

Loading

vlakoff Oct 16, 2017

Ovsyanka Oct 16, 2017 •

edited

Loading

vlakoff Oct 16, 2017 •

edited

Loading

Ovsyanka Oct 17, 2017 •

edited

Loading

Ovsyanka Oct 17, 2017 •

edited

Loading

Ovsyanka Oct 24, 2017

lwille commented Jan 11, 2018

Ovsyanka commented Jan 11, 2018 •

edited

Loading

Ovsyanka commented Jan 15, 2018

Fixed issue #883 #884

Fixed issue #883 #884

Conversation

Ovsyanka commented Feb 3, 2017

lucasmichot commented Feb 3, 2017

Ovsyanka commented Feb 3, 2017

lucasmichot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ovsyanka commented Feb 5, 2017

lucasmichot commented Feb 5, 2017

Ovsyanka commented Feb 5, 2017

lucasmichot commented Feb 5, 2017 via email

Ovsyanka commented Feb 5, 2017 • edited Loading

lucasmichot commented Feb 6, 2017

Ovsyanka commented Feb 7, 2017 • edited Loading

kaufholdr commented Feb 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ovsyanka commented Feb 13, 2017

lucasmichot commented Feb 13, 2017

Ovsyanka commented Feb 13, 2017 • edited Loading

Ovsyanka commented Feb 16, 2017

bensinclair commented Apr 5, 2017

oceanwap commented Jun 6, 2017

vlakoff commented Oct 16, 2017

vlakoff Oct 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ovsyanka Oct 16, 2017 • edited Loading

Choose a reason for hiding this comment

vlakoff Oct 16, 2017 • edited Loading

Choose a reason for hiding this comment

Ovsyanka Oct 17, 2017 • edited Loading

Choose a reason for hiding this comment

Ovsyanka Oct 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lwille commented Jan 11, 2018

Ovsyanka commented Jan 11, 2018 • edited Loading

Ovsyanka commented Jan 15, 2018

Ovsyanka commented Feb 5, 2017 •

edited

Loading

Ovsyanka commented Feb 7, 2017 •

edited

Loading

Ovsyanka commented Feb 13, 2017 •

edited

Loading

vlakoff Oct 16, 2017 •

edited

Loading

Ovsyanka Oct 16, 2017 •

edited

Loading

vlakoff Oct 16, 2017 •

edited

Loading

Ovsyanka Oct 17, 2017 •

edited

Loading

Ovsyanka Oct 17, 2017 •

edited

Loading

Ovsyanka commented Jan 11, 2018 •

edited

Loading