Some people advocate for setting the system timezone on servers to UTC, for various reasons that you can read about with some Internet searches. I don't have the kind of experience that would give me strong opinions on this in general, but what I do know for sure is that for us, it would be a bad mistake to set the system timezone to UTC instead of our local time of America/Toronto. In fact I think we are a great example of a worst case for using UTC as the system timezone.

We, our servers, and most of our users are located in Toronto. Most of the usage of our systems is driven by Toronto's local time (and the Toronto work week), which means that so is when we want to schedule activities like backups, ZFS snapshots, or daily log rotations. When users report things to us they almost always use local Toronto time (eg, 'I had a connection problem at 10am'), and when they aren't in Toronto they generally don't use UTC for their reports. If we used UTC for our system timezone, almost everything we do would require us to translate between UTC time and local time; looking at logs, scheduling activities, investigating problem reports, and so on. Using Toronto's local time means we almost never have to do that.

(And when something happens to our servers because of a power outage, a power surge, an Internet connectivity problem, or whatever, almost all of the reporting and time information on it will be in Toronto local time, not UTC. Almost no one reports things relevant to us in UTC.)

Given all of this, dealing with the twice-yearly DST shift is a small price to pay, and in a sense it is honest to have to deal with it. Our users experience the DST shift, after all, and their usage shifts one hour forwards or backwards relative to UTC.

If we had servers located elsewhere (such as virtual machines in a cloud), we would probably still operate them in Toronto local time. Almost all of the reasons for doing so would still apply, although there might be some problems that now correlated with the local time of the datacenter where they were located.

The more you diverge from this, the more I suspect that it potentially makes sense to set your system timezone to UTC. If you have people working around the world, if your servers are scattered across the globe, if usage is continuous instead of driven by one location or continent, and so on, the less our issues apply to you and the more UTC is a neutral timezone. Running software in UTC also avoids it having to deal with time zone shifts for DST, which means that you don't necessarily have to test how it behaves in the face of DST shifts and then fix the bugs.

(Software sometimes can't avoid dealing with DST shifts at some level in the stack, because it handles or displays times as people perceive them and people definitely perceive DST shifts. But handling time for people is a hard issue in general with no simple solutions.)