Carbon::parse get just date - laravel

I have a date stored as follows:
$user->password_expiry_dt
Carbon #1573228178 {#647 ▼
date: 2019-11-08 15:49:38.0 UTC (+00:00)
}
I want to check if its expired without using the timestamp so currently i'm doing this:
Carbon::parse($user->password_expiry_dt)->hour(0)->minute(0)->second(0) <= Carbon::today()
Is there an easier or more elegant way to get the date without the timestamp as follows without having to chain all these extra setters?
2019-11-08 00:00:00.0

I think Carbon::parse($user->password_expiry_dt)->startOfDay() will do it for you

Related

Adding custom time to date

the timestamp is in a format that I am not able to add to the ruby date. How can I do this?
sd=Date.parse('2016-01-01')
z="4:00am"
How do I add z into sd?
You can't add time to date but you can parse time like this (just concatenate date and time)
date = '2016-01-01'
time = '4:00am'
require 'time'
Time.parse("#{date} #{time}")
# => 2016-01-01 04:00:00 +0300
To avoid some parsing misinterpretation you can explicitly point directives
DateTime.strptime("#{date} #{time}", '%Y-%m-%d %H:%M%p')

Change timezone with Carbon

I have a date that is coming from database (type date):
2018-08-25
This date is in french timezone.
When I do:
$from = Carbon::parse("2018-08-25", 'Europe/Paris');
$from->timezone('UTC');
dd($from);
I get:
date: 2018-08-24 22:00:00.0 UTC (+00:00)
Which is what I want
But when I use field from DB:
$operation = Operation::findOrFail($request->operation);
$from = Carbon::parse($operation->date_ini, 'Europe/Paris');
$from->timezone('UTC');
dd($from);
I get:
date: 2018-08-25 00:00:00.0 UTC (+00:00)
In my DB, field is saved as : 2018-08-25, so literraly, it means 2018-08-25 UTC. So result is coherent. But I'm not sure how to deal with it to get what I want. The implication would be that I have to store my date like a datetime in DB so that I can store it in UTC with 1 or 2 hours less. Is there anyway to avoid this and keep it simple ?
Any idea ?
I solved it using:
$from = Carbon::parse($operation->date_ini)->shiftTimezone('Europe/Paris');;
shiftTimezone with change timezone without changing the date. So, it do the trick for me !
If you call setTimezone() on an existing instance of Carbon, it will change the date/time to the new timezone, for example
$changeTimeZone = \Carbon\Carbon::parse($operation->date_ini)->setTimezone('Asia/Dhaka')->format('H:i');

How to update ends_at field of laravel cashier

I want to update ends_at column of subscriptions table. When i use
Carbon::now()
It update perfectly but when is use
Carbon::now()->addCenturies(5);
I am face error
SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '2520-08-07 11:39:13' for column 'ends_at' at row 1 (SQL: update `subscriptions` set `ends_at` = 2520-08-07 11:39:13, `subscriptions`.`updated_at` = 2020-08-07 11:39:13 where `id` = 1)
i want one subscription for life time due to this i think add centuries. kinldy tell me solution my controller code is
$subscription = $user->newSubscription('default', $plan->plan_id)->create($request->paymentMethod, [ 'email' => $user->email ]);
$subscription->ends_at = Carbon::now()->addCenturies(5);
$subscription->save();
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of 1970-01-01 00:00:01 UTC to 2038-01-19 03:14:07 UTC. Your given year is 2520 and your MySQL can handle year as max 2038.
Change the migration timestamp to dataTime format as :
$table->timestamp('ends_at');
to
$table->dateTime('ends_at');
It looks like ends_at is meant to be managed for you by Laravel Cashier, not something you modify manually. Reviewing the source code, it is only updated based on other values, not any parameters. It also is not used to set any parameters in Stripe API requests. The cancel_at parameter would seem to most likely mapping.
If you wish to set cancel_at, it takes an epoch timestamp (in seconds). As #sta mentioned above, this has a maximum value of 2147483647, representing a time in 2038.
Note also that Subscriptions will by default continue in perpetuity, so it is not necessary to set an "end date" 5 centuries from now.

Converting javascript time with php Carbon returns strange time?

I'm setting my time using javascript when creating/updating my cookie.
// get current time
let d = new Date();
let time = d.getTime();
Which variable time becomes this string...
1586186947954
The number above should result 16:29 GMT 6 April 2020
But when I run this number with carbon...
use Carbon\Carbon;
$updated = Carbon::parse($cart['updated']['time']);
This is returned...
Carbon\Carbon Object
(
[date] => 52234-04-07 05:32:34.000000
[timezone_type] => 1
[timezone] => +00:00
)
Which is way off for reason. Minutes and the date are no where near.
I'm trying to output this timestamp in the timezone Asia/Dubai too if I can get Carbon to return the right time anyway.
Any ideas would be great thanks.
The parse method is for parsing more complex strings, so it is misinterpreting the value you're passing.
You should instead construct the object like this:
Carbon::createFromTimestampMs(1586186947954, 'Asia/Dubai')

Spring data mongodb: Work with dates, date has 2 hours of difference

I've this document stored in mongo:
{
"_id" : "cpd4-734fc2db-a5b0-4881-b5d7-bf85d894178d",
"expiresAt" : ISODate("2018-10-10T00:00:00Z")
}
In order to get sure, all data is right, I've got first the document and I've log some data:
Reference ref = this.mongoTemplate.findById("cpd4-734fc2db-a5b0-4881-b5d7-bf85d894178d", Reference.class);
LOG.info(ref.getExpiresAt().toString());
LOG.info(Long.toString(ref.getExpiresAt().getTime()));
The result is:
Wed Oct 10 02:00:00 CEST 2018 <<<<<<<<<<<<<<<<<<<
1539129600000
As you can see when I get the object, the expiresAt field is 02:00:00 instead of 00:00:00.
Value in database is expiresAt field is: ISODate("2018-10-10T00:00:00Z")
Any ideas or thoughts welcome for this issue!
This date is in Zulu time (note the 'Z' on the end):
ISODate("2018-10-10T00:00:00Z")
When you do this, specifically the call to .toString(), you are converting the date into a local date string in your time zone, which appears to be Zulu+2:
LOG.info(ref.getExpiresAt().toString());
I usually set my server's time zone to UTC/Zulu/GMT, in order to avoid any automatic timezone conversions happening like this.

Resources