Skip to main content

Displaying Booking Info in User Timezone

Premium
9 min read

Comments & Discussion

RA
Richard A. Hoyle ✓ Link copied!

Povilas Korop I am currently in the proses of combining you Travel course and this one in the same project so any help you can give along this lines will be appreciated.

Thanks

M
Modestas ✓ Link copied!

Sorry, not sure what help you need here.

RA
Richard A. Hoyle ✓ Link copied!

Question How can I add the timezone to the Profile so that if the client moves thay can change the timezone for them? Also with in a user edit page?

M
Modestas ✓ Link copied!

All you have to do is re-use the same code on the profile. It's as simple as:

  1. Getting the timezones list
  2. Displaying a select
  3. Updating it with the profile information
UP
Unisoft Prima ✓ Link copied!

Hi, I always store timestamp data in UTC timezone. How to solve Daylight Saving Time issue when convert to local timezome that don't have DST.

M
Modestas ✓ Link copied!

Hi, could you give more details on this?

It should in theory convert the timestamps automatically if:

  1. Your application is set to UTC
  2. Your database is set to UTC
  3. You convert the date from user date to UTC on saving moment
  4. You convertthe date from UTC to user on display

If that doesn't happen - I would love to get some examples to check. DST is built into PHP and should cover your case completely.

UP
Unisoft Prima ✓ Link copied!

I always store created_at timestamp field data in UTC timezone and my application also based on UTC.

So, I just put a function in my Model like this to display datetime based on my local timezone.

protected function serializeDate(DateTimeInterface $date): string { return $date->timezone('Asia/Jakarta')->format('d/m/Y H:i:s); }

However, I encountered an issue regarding Daylight Saving Time.

Normally, when displaying datetime to 'Asia/Jakarta' timezone, the system should add +7 hours, and during Daylight Saving Time +8 hours.

But, at the moment, the system always keeps adding +7 hours.

Could you please advise, how the best way to solve this issue?

M
Modestas ✓ Link copied!

I have just sent a reply to your email about this :)

HN
Huy Nguyen ✓ Link copied!

Hi, I am not sure why we need the middleware "SetTimezoneMiddleware"? What happen if we don't use this middleware in all routes?

Beside, in store method of BookingController, 'start' => fromUserDateTime($request->validated('start')),, as I understand, the function fromUserDateTime above will alway convert $request->validated('start') (datetime local of client) in UTC timezone to UTC timezone, so it seems redundant. I think it only makes sense if we also pass auth()->user() as second parameter as follow 'start' => fromUserDateTime($request->validated('start'), auth()->user()),, so it will convert start in user's timezone to UTC timezone before saving in database.

M
Modestas ✓ Link copied!

You need that middleware as it then globally informs your Carbon package that it should use the specific timezone. If you do not do that - it will simply always use the one from configuration.

As for your question about fromUserDateTime - This function also uses that global Carbon setting. You don't have to pass the timezone/user to it, as that is taken from the Middleware configuration.

HN
Huy Nguyen ✓ Link copied!

I see, but in this logic if (is_string($date)) { return Carbon::parse($date, $timezone)->setTimezone('UTC')->toDateTimeString(); }, when $date is string, the function will convert $date from $timezone(which is default to UTC in this case, not the timezone of user which was set in SetTimezoneMiddleware) to UTC

M
Modestas ✓ Link copied!

Hmm, will have to take a look, maybe there was a little bug left in the code :)

It should work like it works with a carbon instance.

M
Modestas ✓ Link copied!

Okay, so indeed there was a small bug! It was supposed to be a null there in parameters list. Updated the article and added additional tests for this!

Thank you!

RR
Rubens Rocha ✓ Link copied!

In my case, I needed to make some modifications to make it work properly because I encountered some problems.

  1. I modified the Middleware to apply the date/time conversion only in the GET method, thus preventing the timestamps (created_at, updated_at) from being updated with the user's configuration and not the system's. Thus, when a date/time field is filled in, it only needs to use the fromUserDateTime helper (for example).
if($request->method() === 'GET') {
// Code here
}
  1. Still in Middleware, if there is also another middleware that also modifies the Language using App::setLocale, it is better to use Carbon::setLocale(app()->getLocale()); than Carbon::setLocale($localeCode); coming from DateTimeZone.

In my case, using DateTimeZone, it returned only "pt" and not "pt-BR" or "pt_BR", and when using the diffForHumans() method the text was not in the correct language.

  1. Because of the date_default_timezone_set function in the Middleware, I also needed to modify the toUser* helpers, to use Carbon::parse when the $date is of the Carbon type because it was not working correctly.
toUserDateTime(string|Carbon $date, ?User $user = null, string $timezone = 'UTC')
{
    // .....
    if (is_string($date)) {
        return Carbon::parse($date, 'UTC')->setTimezone($timezone)->format($user->datetime_format);
    }
    return Carbon::parse($date->format('Y-m-d H:i:s'), 'UTC')->setTimezone($timezone)->format($user->datetime_format);
}
H
hdaklue ✓ Link copied!

I would make a contract TimeZoneable with method getTimeZone() to ensure $user or any other entity has a timezone variable