Arithmatic signs are not working properly in strtotime - php

Question

I want to fetch the correct date as per the timezones.
ex. I have a time zone +5:30 from GMT. if GMT is 30 aug 2016 1:00 pm then for gmt+5:30 should give me 30 Aug 2016 6:30 pm however, adding timezones like that actually subtracts it rather adding.
I have this code:
$a=date('Y-m-d H:i:s');
which gives me 2016-08-30 07:36:01 as per GMT which is correct.
$b="+5:30";
$c=(strtotime($a.$b));
echo($c);
it gives me 30 Aug 2016 02:08:25 which is wrong I should get 30 Aug 2016 13:10:32.
What I mean is, if I am adding the timezone value it is getting subtracted and if I do same with -5:30 as timezone I get the correct result. Can somebody please suggest what am I doing wrong or how this should work actually.

Answer 1

Use DateTimeZone and DateTime objects to make it more obvious while working with timezone offsets:
$a = "2016-08-30 07:36:01";
$b = "+5:30";
$gmtTz = new \DateTimeZone("GMT");
$offset = new \DateTimeZone($b);
$dt = new \DateTime($a, $gmtTz);
$dt->setTimezone($offset);
echo $dt->format("Y-m-d H:i:s"); // "016-08-30 13:06:01"

Answer 2

Try this:
Solution 1 :
$minutesToBeAdded = 330;
$currentDate = date('Y-m-d H:i:s');
$currentTime = new DateTime($currentDate);
$currentTime->add(new DateInterval('PT' . $minutesToBeAdded . 'M'));
$newTime = $currentTime->format('Y-m-d H:i');
Solution 2 :
$currentDate = date('Y-m-d H:i:s');
$dateTime = new DateTime($currentDate);
$dateTime->modify('+330 minutes');
Solution 3 :
$currentDate = date('Y-m-d H:i:s');
$newTime = strtotime($currentDate . ' + 330 minute');
echo date('Y-m-d H:i:s', $newTime);
I think the above solution will be helpful for you though I haven't tested it.

Answer 3

When you use functions like date and strtotime, PHP converts the inputs you supply according to your date.timezone configuration in PHP, which may not be UTC. So it's important to check, or explicitly set, the timezone before you do the conversion.
$date = "30 Aug 2016 1:00 pm";
date_default_timezone_set("UTC");
var_dump(date_default_timezone_get()); // gives us "UTC"
var_dump(date("Y-m-d H:i:s", strtotime($date))); // 2016-08-30 13:00:00
var_dump(date("Y-m-d H:i:s", strtotime($date . "+5:30"))); // 2016-08-30 07:30:00
So now you're wondering why you just went back in time 5 hours and 30 minutes. Well, if you look at the actual Unix timestamp from strtotime the truth is revealed about what date and strtotime are doing.
var_dump(strtotime("30 Aug 2016 1:00 pm"), strtotime("30 Aug 2016 1:00 pm +5:30"));
This gives you...
int(1472562000)
int(1472542200)
In the first case, strtotime takes the input string "30 Aug 2016 1:00 pm" and converts it to a Unix timestamp under the assumption that we're currently in UTC. In the second case, it takes the input string "30 Aug 2016 1:00 pm +5:30", which already has a GMT offset of +5:30. So it assumes that we're 1:00 PM in GMT+0530, and it tries to convert that back to UTC (i.e +0000), meaning it now needs to subtract 5 hours and 30 minutes to get to UTC, which gives you "30 Aug 2016 7:30 am"
It's easier to avoid all this confusion when you use DateTime, because you can explicitly specify the timezone or the GMT offset and not be subject to implicit timezone conversion. Also, it's important to note that in PHP a timezone is more than just a GMT offset. PHP uses the Olson Timezone Database to reliably and accurately convert date/time information across different timezones, since GMT offsets can actually vary throughout the year in different timezones.
// DateTime doesn't try to convert this because you told it what the timezone is
$dt = new DateTime("30 Aug 2016 1:00 pm", new DateTimezone("UTC"));
// now lets try with the offset
$dt->setTimezone(new DateTimezone("Asia/Kolkata"));
var_dump($dt->format("j M Y g:i a")); // "30 Aug 2016 6:30 pm"
Notice, there's no need for you to actually mess around with how many hours/minutes to add/subtract. PHP figures it all out by looking up the needed timezone information in the database. Because we correctly specified the timezone supplied and the timezone converted we can rest assured we always have the accurate time regardless of how many times we subsequently convert between timezones. It's a far more reliable abstraction than what you're trying to do.