Same!
There's still apps at my company that use the server's local time for everything, built in a pre-cloud world. Now we "cloud host" many of these, by running sets of VMs with their clocks set to different timezones and setting up each tenant on one matching their zone. Unfortunately, it's a product that makes a fair bit of money but isn't our focus (not much growth or new sales), so it's never been worth it to actually do something better.
It's not just the timezone/DST issues, either. Another product I've worked on did the "reports at midnight" thing, but as it grew it became impossible, as it took hours to complete all reports for all customers. So some "scheduled at midnight reports" would happen at 1:28am. This alone isn't a huge deal, but many reports were time-dependent (eg: you get different results running at 1:28 vs 0:00), and for a subset of those it was actually a big problem. So some got fixed by removing the time dependency (basically making the queries in the report have end times vs using now()). Another workaround was to staggering times manually on other reports - run at 2:30am - but still many customers would still pick 1:00 or 2:00 (which is of course someone elses' midnight), and there were still big I/O bursts on :00, :30, :15 and :45, especially overnight.
My personal takeaway was to avoid building report systems like that, and try to do things like let the user pick "Daily" without picking the time-of-day. For time-sensitive "reports" it's been my experience that if you actually dig into the user needs, they're really looking for an "operational view", not a report. It requires specific dev work to build of course, but the end result is better both technically and for the customer, and is less overall work than all the fixes/workarounds needed when you try to shoehorn it in with all the other reports, especially as the usage grows.