Which was my point, I thought I made clear, from the very beginning. Keeping up with software updates (that theoretically aren't supposed to change anything unless they make it better, even if it means an API difference to code to) is one thing. Generally, one can hold back a patch and coordinate it with some other release cycle.
Having to adapt to an arbitrary, non-technical reason mandated by a clueless government is something else, a very EXPENSIVE, something else, as it is as i noted, something that adds no value to the product but costs as much as a new large feature would. And in this case, the deadline wasn't set by us either, but by the same government - we couldn't hold the patches back. Quite the opposite, we needed to get them in and tested ASAP as customers using our app to project into the future needed to have that date information accurate.
My response (see the title this thread has had all along) was in response to the continual suggestions that happen twice a year, every year, right on schedule, for getting rid of DST, but clueless dolts who think it is "easy" to do and wouldn't have any impact except some alleged positive one based on some analyst's arbitrary definition of "productivity". While getting rid of DST might eventually have a long term benefit, it will still have an expensive short-term cost that needs to be carefully considered based on the experiences of 2005-2007.