Good for them. It makes much more sense to shift government/business hours if needed than constantly mucking with the time and screwing up millions of software installations.
No. Every piece of software that deals with time in any kind of sophistication needs to have logic to handle it.
I used to work on a share price alerting system where you could say "if the price of stock X goes up by 10% during these hours than alert me", that creates a nightmare when it comes to DST changes. Do you use the timezone of the person who setup that alert (what if they're now in a different timezone do you change ?) or do you use the DST rules of the country the share trades in.
Imagine you have a calendaring app and someone from another country sends you a meeting request for the future that's past a DST change in one of your countries, but not past it in the other. It's possible for the time to be ambiguous unless you specify DST handling rules. What happens if a country changes DST rules (this happens far more often than you think) how do you adjust previously set appointments ?
Imagine your Google Analytics, what timezone do you save analytics data in and do you adjust for DST (the answer is PST by default, and if you change it, historical data won't be adjusted so you end up with a mishmash of time data).
In any scenario where you have to handle timezones it's complicated enough as it is, DST handling makes it a nightmare.
Unix-like systems like Linux and OSX handle that very well.
The hardware real time clock ticks in UTC, file timestamps and the like are stored in UTC. The OS knows everything about time zones and DST and therefore can display the time the way you expect it.
The problem goes the other way. If a user says, "run this job at 1:10AM", does the job run twice when 2am becomes 1am at the DST switch? If everyone input times in UTC, it would be fine, but users want to input and output.
I am lucky to be able to avoid this problem, because while I do have users that want to read and write times in their local time zone, they are asleep at 1am and automated stuff tends to run at midnight. Sometimes the dice roll in your favor :)
Current time is only a small part of time handling, practically every crontab implementation handles DST differently due to the ambiguity in the posix standard which just states that time stamps have to be in local time taking no account that this can mean a scheduled task can incorrectly get run twice or never.
Not really. On *nixes, there's a library called zoneinfo (http://en.wikipedia.org/wiki/Tz_database) that has the list of rules about "if you're in living in California, then DST starts on March 23" or whatever. When a country changes the law about when DST is, that data needs to be updated.
That can cause headaches, if you have a mission critical system that needs to be updated, otherwise it may do something important an hour early, or an hour late. For example, Postgres has to be rebooted when the timezone information is changed.
Software is often written with the assumption that time always goes forward, because, well, that's how time works. However, according to the rules of daylight savings, time actually goes backwards once a year.
This was resolved a long, long time ago - it's why we have a timezone file, so we can keep the system in GMT and have it convert user-interface stuff for the user.
Software is often written in ignorance of this fact - and causes headaches whenever things change.
If by "automatically", you mean "after thousands of man-hours have been taken to implement and debug the process" - and then only for so long as the system remains precisely the same.