Depends on the time zone and changes to it. If it's a timezone without seasonal changes and its other properties don't change during the life of the organization, that's fine; maybe it's not ideal, but it's fine.
If it's a timezone that has its operational properties change, you have the potential for confusion where there is disagrement about when a given time happened or will happen; think about how fun it is when daylight savings rules change. Sometimes, although not really that often, a time zone's offset is simply changed; hopefully with warning, but maybe not.
If the timezone has daylight savings, you get to deal with all the fun of most days having 24 hours, but some having more or less.
If the organization moves to a new time zone, either because it physically moves or because the locality its in changes time zones for whatever reason, now you have a problem; it's not fun to deal with multiple time zones in server infrastructure, but now you have to pick if you want to move all the servers, move only some servers, or have your servers in a different time zone than your org. If the last option was fine, you might as well use a sensible timezone to begin with.
You can always interpret the timezone on the app/client/presentation side, I can't think of any scenario that is made better by the server itself being set on local time zone. It causes extremely messy issues IME.
1. If the time zone changes (like, as it's happened multiple times in my country, the date for switching to daylight savings changes) you have to make sure all your servers is updated with the change
2. Daylight savings mean that events an hour apart can end up having the same timestamp.
I've fortunately never experienced (1), but for (2), it helps to print the offset to UTC everywhere timestamps are printed, even for UTC. (I basically never trust an "unzoned" timestamp.)
I guess you’ve never had to correct the local time to UTC for handoff to a different system and the conversion was buggy in the wrong direction? Or haven’t had to figure out which 2:30am something happened? Or why something that usually takes a second took an hour?
I've had to do all of these things many times, but keeping server times on UTC doesn't really help with most of them:
Customers, partners, stakeholders all think in terms of local time zones, as do I; some amount of conversion is inevitable.
Ultimately, local time is a presentation layer concept, so why shouldn't I configure that presentation layer so that I have to do one less conversion in the most common case (of figuring out when something happened relative to my wristwatch or that of most of my customers)?
Are you saying you should configure the server to local time to save you one less configuration on the presentation layer? That doesn't make sense to me. I really can't think of any benefits to setting the server to local time that doesn't offset the huge load of negatives.
Here's something you may not be thinking about - your presentation layer may save a configuration step, but now every system that interacts with your server (who have all likely defaulted to UTC) have to know about this now. Think - logging infrastructure, schedulers, cloud infra, etc. So now you have to configure all those as well. Anything that touches the host will need to be reconfigured to save one very minor and commonly done thing on the presentation layer. Really doesn't make sense, as an infra guy.
> every system that interacts with your server (who have all likely defaulted to UTC) have to know about this now.
No, why? Almost all APIs/interfaces use zoned timestamps or seconds since the Unix epoch.
The argument of “servers must run in UTC” sounds a bit like “servers must run with an English locale” to me in that sense, as if the locale changed the name of API parameters or enum values instead of just human-readable strings.
