I had the opportunity to program some phone systems for a company, built on a hardened operating system with a *nix favour. The exact one doesn't matter, but I found that it had a simple technical deficiency, related to daylight savings time.
The system appeared to have incorrect daylight savings time databases, and yet the system relied on time-of-day information to present call prompts to users. For example, shuffling a call to a menu if the call occurred during the company hours versus another if the call occurred during non-hours. Quickly I brought forward a support request with the owning company of the software, which the client had a support contract with. "Just set the time zone to the one that matches, and set it back later." was the gist of the reply I received.
That bothered me. It seems like a pretty obvious problem. If your software relies on scheduling, it should coerce its behavior to that of anything time related in the world, for as long as it is relying on our region's time. If the software doesn't have an automatic update process - then there should be some method of "hacking" the problem to set it and forget it. (I heard that on an info-mercial once...)
In this particular customer's scenario, I could log in and set a custom timezone, which the support person should have announced to me, but it was I that happened to remember that option during the setup process when initially configuring the system.
These hardened phone systems or firewalls or other systems that have features such as time zone manipulation removed really have their work cut out for them when it comes to these regional changes. In fact, a simple piece of software to calculate time differences suddenly becomes complex as we have to ask which timezone and more specifically where, and now even - which places are shifting timezones to accommodate energy savings initiatives.
We definitely will use these thought practices in our solutions when we can.