Best way to handle converting existing laravel application from local timezone to UTC

Question

Currently, in our Laravel application, we have the timezone set as followed.

 'timezone' => env('TIMEZONE', 'Europe/London'),

All our DateTime and timestamps fields in our MySQL database are also stored in the Europe/London timezone.

Our application is now going to switch over to UTC , however as BST is currently an hour out at the moment if we change the TIMEZONE to UTC in our application all our existing infrastructure will break.

The things that will break include our existing queries using time fields as they will be an hour out of sync with the records in the database.

An example of where we use time in our system within queries is as followed

Task::where('expired', '=', false)->where('expires_at', '<', Carbon::now())->get();

With the code example above tasks would be expired an hour early because UTC is one hour behind BST .

As changing to UTC will be a fundamental change for a system I was hoping I could get answers to the following questions.

1. Are there any resources out there that outline ways of converting a system from a local time zone to UTC?
2. Instead of converting to UTC should I store everything in Europe/London and then convert it for the user on the frontend?
3. Is there any way to easily query a database table that has multiple timezones in it?

Thanks for any help, I know this question is difficult so anything that can point me in the right direction would be greatly appreciated.

Answer 1

Can't say anything about the first item in your list, and here is what I think about the second. There are actually quite a few timezones you should be aware of: default php timezone (the one from php.ini), server timezone (afaik, if php.ini timezone is empty, it falls back to the one from a server), mysql's timezone, server timezone where mysql instance is deployed, your timezone where you currently are, your users' timezone, and not to mention such exoteric things like mysql connection timezone.

With that said, if you don't want to have a pretty fun time debugging fancy error, you want all system timezones to be the same. Actually, it doesn't matter what exactly it is. More important, you're aware of each of them, and know how they apply to your situation. Having all of your system timezones as UTC is just more predictable, more universal, more common.

But if I were you, I would leave infrastructure timezone settings as they are. I doubt you gain anything tangible with this move. Converting datetimes on a frontend is actually a common way of dealing with stuff like that. For example, in postgres it's possible to save a timezone along with a datetime, but it's pretty much useless, since it's converted into a system timezone. So when I need to output a datetime to a client, I write something like

(new AdjustedAccordingToTimeZone(
    new FromISO8601('2018-04-25 15:08:01+00:00'),
    new Moscow()
))
    ->value();

Regarding your third question, quick googling pointed me at this one . So if you query several rows, each of which has its own timezone, you can always convert those dates to any timezone you wish.