Welcome to the time zone nightmare. I'm sorry that that was a very, very poor attempt at being dramatic. But you know, sometimes whenever you work with dates and times it can be dramatic because on the surface it's relatively easy until you have to get into leap days, leap minutes, leap seconds. It's crazy. Thankfully we don't have to do that and a lot of the times all we have to do is work

It's crazy. Thankfully we don't have to do that and a lot of the times all we have to do is work with time zones. Time zones can be a little complicated, but really there are two rules when it comes to working with time zones. If you are running an application that has to take time zones into account, the first rule is to store your date and time as UTC in the database, no exceptions

to store your date and time as UTC in the database, no exceptions because you will eventually have to convert that into the user's local time zone. And that's a whole lot easier to do if your dates are stored as UTC. So go with that. Now, if you're writing a little application that doesn't have to take time zone into account, you know who cares stored in local time, it doesn't matter.

that doesn't have to take time zone into account, you know who cares stored in local time, it doesn't matter. But anytime you work with time zones, you want your dates to be UTC. So that's the first rule. The second rule is whenever you display your date and time, that is when you convert it so you don't convert it before you can convert on display. So as we display the date and time of these orders, we need to convert it into

So as we display the date and time of these orders, we need to convert it into the user's local date, time or local time zone. Unfortunately, uh, Samir Monaghan wrote us and said that, you know, the dates and times of the orders aren't correct. Of course the minutes are because you know minutes, but the dates and the hours are not correct. So this one says January 28th, he placed it on January 29th, January 26th, you know, and, and so on and so forth.

So this one says January 28th, he placed it on January 29th, January 26th, you know, and, and so on and so forth. He, he's in Australia by the way. So there's a big discrepancy between, you know, dates in UTC and Australian time. But that's gonna give us a clue as to what the problem is because if these are wrong, then chances are we aren't converting into the appropriate time zone. So if we take a look at our view, that's indeed the case

the appropriate time zone. So if we take a look at our view, that's indeed the case because uh, at least we did one thing right here. We stored our dates and times in UTC, so that's good. We are also converting our placed at attribute as date time. So we get a carbon object that we can use, which means that in order to convert this to the user's time zone, all we really have to do is just call time zone and then we can pass in the user's time zone

all we really have to do is just call time zone and then we can pass in the user's time zone and we have that as part of the user's profile. We just have to get the user so that we can get their time zone and pass that to the time zone method. So if we take a look at this, then voila, we have the correct date and time for Samir. So we've just fixed that bug. All you have to do is just go to the other places

So we've just fixed that bug. All you have to do is just go to the other places where we display the date and time and we're done or not. Because who wants to write all of that out? Who wants to read that dad gum? I certainly don't. So there's a couple of other options that we can do. This works and there's something to say about code that works. There's also something to say about code that is difficult to read.

There's also something to say about code that is difficult to read. So one thing that we could do is just have a helper function, and I have one already. It's called user time. We just need to pass in the date and time that we want to convert to the user's time zone. And if we take a look at our helpers, here is the user time function.

And if we take a look at our helpers, here is the user time function. So we get the date time, if it's a string, then we convert it into a carbon instance. We get the time zone and then we set the time zone for that date and time. So we're still working with carbon dates and this is gonna work so that we convert it, then we format it and we're gonna end up with the same results.

then we format it and we're gonna end up with the same results. And that's great that that's a whole lot better than what it was, but I want something that's still much more readable And I kind of like the idea of using a component. Maybe we could have something called date time, which would have a date prop and then we would just supply the order placed at attribute there and then that's it.

and then we would just supply the order placed at attribute there and then that's it. I mean that is so much easier to read and understand and um, yeah, that that's what we're gonna do. So let's write that and it's not gonna take long. Let's first of all pull up the console so that we can make a component. I will just call this date time and we don't need a class, we'll just have the view there. So if we open up date, time, blade dot PHP, uh,

and we don't need a class, we'll just have the view there. So if we open up date, time, blade dot PHP, uh, and this is one of the really cool things about this, we can use the time and I like that. So first of all, let's define our props. Uh, we essentially need two props. In fact, what I want to do, if we go back to our helpers, I essentially want to make this user time as a component. So we need the date as the first prop.

as a component. So we need the date as the first prop. So uh, we will have our props called date. Then we'll have another prop for the format. And this is where we can set a default value. So we can just take this format here and use that as the default value for our format. So now we have that and all we have to do is just use the time element that we have.

and all we have to do is just use the time element that we have. So we'll set its date, time attribute, and let's do this. We'll just take the date and we'll call two ISO eighty six oh one string. That'll be the value for that attribute so that then we can output the user time. We will pass in the date and pass in the format because do we format? No, we, we just take the time zone.

because do we format? No, we, we just take the time zone. But okay, so that means we need to pass in the date, then we call format passing in the format and there we go. So we end up with essentially the same result, except that now we are using the time element and whenever we view this in the browser, we are going to see nothing because I did this completely wrong. Uh, that needs to be quotes there. So now we will see our date

Uh, that needs to be quotes there. So now we will see our date and time, which means that to every other place that we show our date and time, we now have a nice elegant way of outputting that information. So for the show view, it's right here. We'll just use that. And whenever we view the details of this order, if we scroll on down, we have the date and time, although now we can get rid of this UTC

if we scroll on down, we have the date and time, although now we can get rid of this UTC 'cause it's not UTC anymore. It is within the user's local time zone. So here's how you can prevent time zone bugs in your applications. First and foremost, always store your dates and time in UTC, just do it. It makes converting to any time zone so much easier. It makes data and time arithmetic so much easier.

It makes converting to any time zone so much easier. It makes data and time arithmetic so much easier. So just store in UTC, that's gonna solve a huge part of any problem that you're gonna have with date and time and time zones. Second, convert only on display. You don't want to convert to the local time zone before you store it in the database or anything like that. The time zone is really only something that we want to use when we display the date and time.

The time zone is really only something that we want to use when we display the date and time. I can't think of really any other reason why and I'm sure that there is, but you know, don't convert it before storing it. Just convert to the local time zone when you display it to the user. And you know, I say all of these are the most important thing, but when it comes to working with multiple time zones,

of these are the most important thing, but when it comes to working with multiple time zones, you need to test with multiple time zones. So add time zone testing to your test suite.