Like this
$Datetime = new DateTime($time);
$Datetime->modify('-6 months');
echo $Datetime->format('Y-m-d');
http://php.net/manual/en/class.datetime.php
UPDATE
What is this?
But I again the need the timestamp format since I save this as integer (laravel). Is there a better way of doing this
I mean what does the int look like. You can use something like this DateTime::createfromformat( 'Y-m-d', '2018-01-01')
And then output it as a timestamp with $Datetime->gettimestamp();
So the full code would close to:
$Datetime- = DateTime::createfromformat( '{your date format}', $datestring);
$Datetime->modify('-6 months');
$timestamp = $Datetime->gettimestamp();
You should not subtract an arbitrary number of seconds, because that wont account for leap years, or months with odd numbered days. Date time relative formats are provided especially for doing this, so it's best to use them.
UPDATE2 ( for Carbon )
If you look at the source for Carbon
its an extension of DateTime
and thus probably provides the same functionality, and a bit more. So even this may work Carbon::createFromTimestamp($begin, Timezone::IST)->subMonths(6)->gettimestamp()
As this tid bit from the carbon source shows
public function diffInSeconds(Carbon $dt = null, $abs = true)
{
$dt = $dt ?: static::now($this->getTimezone());
$value = $dt->getTimestamp() - $this->getTimestamp();
return $abs ? abs($value) : $value;
}
Specifically $this->getTimestamp()
, this is no big surprise as it extends DateTime. That said, I would avoid using the public property of timestamp
as it violates the Black Box Protocol ( this is what I call it (BBP)) where a class should be a black box for it's functionality. And you should only access data from a class using it's public interface ( which interfaces do not contain properties ) That's just my Opinion though.
Now if you were to really dig into the source code for carbon, then this code Carbon::createFromTimestamp($begin, Timezone::IST)->subMonths(6)
probably does something very much like this:
$this->datetime = new Datetime($begin, Timezone::IST);
$this->datetime->modify('-6 months');
Specifically
class Carbon extends DateTime{
//-------- create---------
public static function createFromTimestamp($timestamp, $tz = null)
{
return static::now($tz)->setTimestamp($timestamp);
}
public static function now($tz = null)
{
return new static(null, $tz);
}
/*
the code "new static" can be a bit confusing, but this is just
one of many ways to call "new Carbon()", which in turn is calling
new "DateTime()". They use static so if you extended Carbon it will
work (as opposed to using "new self") a.k.a "new static" uses late
static binding. And they also use static, because it's cleaner then
doing something like "new __CLASS__", which I believe will not let
you pass in arguments (without assigning the class name to a
variable). Where as new static($arg) works fine. In any case it's
generally preferred to use something like "new static" then to
reference the class name directly as in "new Carbon". Obviously
this is so if the class name changes there are no repercussions on
the code, no code to update.
*/
//-------- subMonth ---------
public function subMonth($value = 1)
{
return $this->subMonths($value);
}
public function subMonths($value)
{
return $this->addMonths(-1 * $value);
}
public function addMonths($value)
{
if (static::shouldOverflowMonths()) {
return $this->addMonthsWithOverflow($value);
}
return $this->addMonthsNoOverflow($value);
}
public function addMonthsWithOverflow($value)
{
return $this->modify((int) $value.' month');
}
public function addMonthWithOverflow($value = 1)
{
return $this->addMonthsWithOverflow($value);
}
}
So it calls like 4 or 6 additional function calls, but in the end it's basically the same. Taken right from the github source code.
For creating they are just making a DateTime
object (child) with the current day and then setting the date in it with the timestamp.
All they are doing is taking the 6
you give them *-1
so it's -6
then doing $this->modify('-6 months')
which as it extends DateTime
is roughly equivalent.
Basically all the code I pasted above, can be done in 3 lines. But, if it was me I would still use Carbon, as it's the "frameworks" way of doing it, so it's a tad bit more proper. Also function calls are cheep, and performance wise you wont really notice the few nanosecond difference. So as always I would lean to Readability ( within the framework ) over performance.
As a side I never used Carbon
but it looks interesting. I delved a bit deeper then I probably should have, but I have been thinking of making something very similar, so perhaps I will just "composer in" Carbon ... lol ... The older I get the lazier I am, 6 years ago, I would have just hammered away at the keys tell I had something very similar to it. But composer wasn't around then, so ...