Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
A client ordered a booking system: they wanted a seven day schedule (Mon-Sun) that would allow for people to book an hour on each day. This system is global, so it's based on UTC.
Basically, the user picks a day - let's say Monday - and a time (12:pm EST) and reserves that block. So we store it like so:
reserved_day = 1;
reserved_time = 5:00:00
Day 1 = Monday
5:00:00 = 12:pm EST UTC.
So this means if you're in the America/Los_Angeles time zone, you'd see this as 9:00 am Monday. It's working as it should.
Keep in mind this is not a calendar app; there are only 168 blocks of time available to book (24 hours in a day * 7 days), so Monday has 24 blocks, Tuesday has 24 blocks, etc.
Now here's the rub: if someone books in Asia, where it's a day ahead, should the app be able to reflect that? So if someone in Bangkok registers on a Monday, should a person in Chicago see that as a reserved time on Tuesday? Or should they see it as reserved time on Monday?
If you think they should see it on a Tuesday, how is this accomplished? Carbon timezone only seems to do the hours, not the days.
Maybe you could refine your explanation for more context. If the user books a slot at 1200 ET, then you can convert that to UTC (1600) right away. Then, if someone viewed that slot in Los Angeles, the 1600 UTC would convert to 2100 UTC. In your case, I would use timestamps for the reference because then the calendar dates will convert correctly.
I would just store it as one value, a timestamp ie (reserved). Then your server-side logic can determine reserved_day and reserved_time off of the timestamp as well as handle the timezone across different days correctly.
As far as which time to display, is this a virtual appointment (meaning they will be in their timezone for this appointment)? If so then I would absolutely use the timezone offset. If they will be traveling to where the appointment is, then I would use the local time for that location.
@EJDELMONICO - Yes, I already have that working. My problem is with international conversion, which I'm actually not sure is possible without a full date.
@WILLJOHNATHAN - Yes, they will be in their timezone, but it has to show a user across the planet that that hour has been reserverd in THEIR timezone, which means it has to shift days. If someone in Asia schedules on a Monday, someone in the US will see that on a Tuesday. Not sure this is actually possible without using full dates...
@TIMGAVIN - You need a full date... which is what a timestamp is. Laravel stores the time in the db according to the app variable: config('app.timezone') . I would recomend that you store your datetime in utc; but if not you can always do something like this (assuming "reserved" is a timestamp in your db):
Reservation.php (or whatever your model is called)
public function getReservedDatAttribute()
{
return $this
->reserved
->timezone(config('app.timezone'))
->tz($value)
->dayOfWeek;
}
public function getReservedHourAttribute()
{
return $this
->reserved
->timezone(config('app.timezone'))
->tz($value)
->format('hh:mm:ss');
}
This will add the reserved_day and reserved_hour attributes to a model in the users timezone. You might need to take a slightly different approach (maybe setAttribute instead of getAttribute) depending on how you get the users timezone.
Please or to participate in this conversation.