Carbon: addDay() not adding a full day when timezone set?

[ozziexsh]

Example:

>>> use Carbon\Carbon
>>> $day = Carbon::parse('2017-01-24T00:00:00-10:00');
=> Carbon\Carbon {#789
     +"date": "2017-01-24 00:00:00.000000",
     +"timezone_type": 1,
     +"timezone": "-10:00",
   }
>>> $day->addDay()
=> Carbon\Carbon {#789
     +"date": "2017-01-25 00:00:00.000000",
     +"timezone_type": 1,
     +"timezone": "-10:00",
   }
>>> $day->addDay()
=> Carbon\Carbon {#789
     +"date": "2017-01-25 14:00:00.000000",
     +"timezone_type": 1,
     +"timezone": "-10:00",
   }
>>>

The first call to add day adds a full day, but subsequent calls only add 14 hours?

[armgabrielyan]

I am not able to reproduce this bug (see in the picture). Please provide more details.

[spantaleev]

Not sure if it's the same exact problem as described, but here's another case of addDay() not working well when a timezone is set.

In Carbon 1.22:

$day = \Carbon\Carbon::create(2017, 11, 05, 0, 0, 0, 'America/New_York');
echo $day->format('Y-m-d H:i:s'), '<br />';
$day->addDay();
echo $day->format('Y-m-d H:i:s'), '<br />';

produces

2017-11-05 00:00:00
2017-11-05 23:00:00

Note how we remain within the same day (5th of November).

---

In Carbon <1.22, the same code produces:

2017-11-05 00:00:00
2017-11-06 00:00:00

---

This seems to be a regression caused by 5394301dee302c29f85504d7272d5c9534b49d05.

It's not a general problem with addDay() - it doesn't always happen.
In this case it seems to be caused by DST changes for the America/New_York timezone on that specific date:

Next Scheduled DST Transition
DST will end on Sun 5-Nov-2017 at 02:00:00 A.M. when local clocks are set backward 1 hour

[sergiodebcn]

+1 same problem here, we fixed the problemb installing previous version 1.21

[marc-tomas-atrapalo]

I think addDay() should add a day and not 24h. If there is a 25h day or a 23h day with DST that should be hidden under the addDay() function.
It should not happen to use the the addDay() function and end in the same day.

[Ovsyanka]

It relates to #883, I think.

[peric]

I've also stumbled upon this bug/feature today, which worked as expected in previous versions of Carbon. I will temporary fix it by adding a day with \DateInterval object with 'P1D' interval.

But, I would say that addDay() method should always add a fixed 24h to the previous value. If we have a date-time 2017-10-28 10:30:00 in Europe/Warsaw timezone, addDay() method should return 2017-10-29 10:30:00, and not 2017-10-28 09:30:00 because DST ends between those two dates.

At least in my opinion, it should work like that. Because, as a user, I would expect that 10:30 will always be 10:30 - we're not adjusting all the schedules and opening times, we are just moving clock back.

[Ovsyanka]

@peric, plz look to https://github.com/briannesbitt/Carbon/issues/883#issuecomment-277109121 and https://github.com/briannesbitt/Carbon/issues/883#issuecomment-277242593

By now we stand on the my vision how it sould work. If you don't agree with that - please write about it in the #883. We have to reach consensus on this question. _I think we should discuss it there (not here)_

[Ovsyanka]

@peric, and seems like you messed up a little. You wrote

But, I would say that addDay() method should always add a fixed 24h to the previous value. If we have a date-time 2017-10-28 10:30:00 in Europe/Warsaw timezone, addDay() method should return 2017-10-29 10:30:00, and not 2017-10-28 09:30:00 because DST ends between those two dates.

But 2017-10-28 10:30:00 +02:00 plus 24 hours will be 2017-10-29 9:30:00 +01:00, not the 2017-10-29 10:30:00 +01:00. Pay attention to offset. 2017-10-29 9:30:00 +01:00 is the same moment as 2017-10-29 10:30:00 +02:00. If you don't get it - ask me, I will try to explain more verbosely.

[matejvelikonja]

@Ovsyanka I have to agree with @peric. Adding a day should leave the time alone. This is not an expected behaviour.

For example: if I say to someone that we should meet in a day at the same time, this should not mean that we meet 1 hour earlier.

I think you should distinguish between adding 24 hours or 1 day.
Day does not have 24 hours always. Once per year a day has 23h and once 25h. Of course if you live in a timezone where DST occurs.

[peric]

I agree with @matejvelikonja. As he said, adding hours and adding days should work different when DST starts/ends.

And as I understood, this was also the point in https://github.com/briannesbitt/Carbon/issues/88. The issue affected adding hours, not adding days.

[Ovsyanka]

For example: if I say to someone that we should meet in a day at the same time, this should not mean that we meet 1 hour earlier.

Yeees, so, you talking just like me in https://github.com/briannesbitt/Carbon/issues/883#issuecomment-277109121 (in matter of time units > hour).

But the same logic could looks odd with the units <= hour. If I want to see you after one hour, I want to see you after 1 hour doesn't matter what time of a day it will be.

Please, if you want to discuss how it should work with others - do it in #883, because there is the issue I relating my pull-request to. And I dont want to write same things in more that one issue. But try to carefully investigate a question and initial problem. https://github.com/briannesbitt/Carbon/issues/883#issuecomment-339446962 here is my current suggestion to discuss.

[Glavic]

Fixed in #1129.