I'm using Carbon inside of my Laravel API project, when trying to set the timezone and get a datetime back in the user's timezone, I'm for some reason getting a UTC value back, what am I doing wrong?
// $user->timezone will give me "America/Curacao" or whatever their time zone is
$curr = Carbon::now()->setTimezone($user->timezone)
But when I echo out the contents of $curr, I'm getting a UTC time of:
2021-04-05T11:58:35.186750Z
What am I missing?
You get the ISO-8601 string with is the standard format for dates in JSON. But the object is correctly in America/Curacao timezone. If you want to pass it to a Date object in the browser, you don't need the timezone and can just pass this string as is.
If you want to format the date to be seen by the user, then just pick the format after setting the timezone:
$curr = Carbon::now()->setTimezone($user->timezone)->format('Y-m-d H:i:s')
Or whatever format would be relevant for you.
And you should keep 'timezone' => 'UTC' in your app settings as your users will likely have any various timezone, and UTC is the more agnostic to use to save them back-end side.
Related
I'm trying to understand the following.
On my config/app.php I'm having my local timezone set to:
'timezone' => 'Europe/Athens'
My Postgres is set to:
SHOW timezone; // returns UTC
In the inserted rows in Postgres i would expect to see my local timezone, converted to UTC. Instead, the timestamp is written on my local timezone.
In another Node.js application, in which I'm working on, with another Postgres instance, when i insert a new row, the local timezone is converted to UTC while the timestamp is stored.
Why this is different on my Laravel app?
What is the case here?
I'm struggling with the Carbon::now(), I'm specifying the desired timezone in the now function and it is not giving the date time based on the given timezone. It always using the UTC timezone that's specified in the laravel.
Carbon::now() // giving me date time of UTC timezone
Carbon::now('Asia/Karachi') // still giving me the date time of UTC timezone
var_dump(Carbon::now('Asia/Karachi')) // I'm able to see the correct date time based on the timezone.
So when I use the var_dump() I'm getting the correct date time based on the give timezone. Can anyone explain why it is nog returning the correct timezone from the Carbon::now('Asia/Karachi')? but dumping the instance showing the correct datetime.
I've also tried the php artisan cache:clear as well as php artisan config:clear
In config/app.php file change UTC to your desired timezone. It will change app timezone globally.
Eg:
'timezone' => 'Asia/Dhaka',
It always using the UTC timezone
Where? If you're talking about a JSON output, it's expected, date is formatted with ISO-8601 string and a trailing Z meaning Zulu = GMT timezone. The browser or client reading this JSON will have no issue to reconvert it then to any local date time using the user device timezone.
But at anytime if you dump explicitly this instance to a string using any format, the specified timezone will be used:
Carbon::now('Asia/Karachi')->format('Y-m-d H:i:s.u p')
(here using p or e you will see explicitly the timezone in the string.
I'm trying to compare a start date of an event resource I have with the now date. All dates are being stored as UTC and then the timezone is set according to the user's timezone.
But when I compare the dates the difference is always the same regardless of the timezone I set. It's always being evaluated as UTC. So for instance when I set
$now = Carbon::now()->tz($profileTimezone);
And then try to compare it with another date
$difference = $now->diffInHours($event->starts_at));
It's always returning the same difference object with the same values regardless of the timezone I set for now. Shouldn't the difference in hours, for example, change when now is in a different timezone?
When running the tz method it will convert the datetime object to that timezone. Meaning if you change now to a timezone which is 1 hour behind from the current timezone, it will subtract that hour from the time.
What you are looking for is the method shiftTimezone, that one will change the timezone without changing the time also.
Carbon::now();
// 2019-07-29 12:53:29.575769 UTC (+00:00)
Carbon::now()->shiftTimezone('Asia/Phnom_Penh');
// 2019-07-29 12:53:29.572207 Asia/Phnom_Penh (+07:00)
Carbon::now()->tz('Asia/Phnom_Penh');
// 2019-07-29 19:53:29.575776 Asia/Phnom_Penh (+07:00)
I saved a record in 17:16:15, I run a job which gets the ModifiedOn field of my record and I got- 15:16:15, my GMT is +2, I want to know how to fix that gap that my result will turn out like it should be - 17:16:15. I can't select it from DB I need a solution in server side (c# I mean) what can U do in that case?
DateTimes are always saved in UTC in the database. *
You need to dynamically convert from UTC into your local time zone. In C#, you can do this with the .ToLocalTime() method as long as your code is running in the correct time zone. You can also find your local time in the FormattedValues collection of the response, which uses your Dynamics timezone user settings . But the raw datetime value in the database will always be in UTC.
* The only exception to this is if the DateTime field is set to “TimeZone Independent” in the attribute type settings. But be careful: once you set this option you can’t change it for that field again.
I currently store all dateTimes in the DB as UTC dates. Each users time zone offset is also stored in the DB. When I retrieve a Date it is converted back to their local date using this offset.
The problem occurs when I retrieve a date using an ajax call. The date (which is already converted using the offset) is, I think, returned as a Java Date object. The browser then decides to mess with my Date adding the clients computers time zone offset to the Date object. This is causing dates to be a day ahead of what they should be if the time component is more than 11.59am.
The only solution I can come up with is to pass them as strings in which case this of course wouldn't happen. This is a laaaast resort for me though and I would love to find a better solution or workaround for this problem.
Your browser is not messing with the dates given that browsers don't have a native date transfer variable. You have something else that is doing that. How are you sending your dates in ajax? Json? Json will only send numbers or strings. XML will only send strings.
Something is converting your sent date into a javascript date object, find out what it is.