It makes a HUGE difference exactly what the application is. Changing the time automatically can indeed be "nice" but it can also be a pain, and even dangerous.
For real-time embedded applications that control things, I vote with someone else who said often times the best and simplest way to do it is have the user do it manually. True, a step is required to do that, but the step provides acknowledgement and awareness of the time change and any consequences that might result from it.
If an automatic irrigation sprayer is supposed to run at 1:30 AM, in the fall when the time sets back, it will run twice since 1:30 occurrs twice that morning, one hour apart. Then in the spring when the time goes forward, the sprayer will not run at all that morning since there will not a 1:30 AM.
A couple of reasons the 1:00 AM to 2:00 AM period to change the time was chosen are: a) not many things are scheculed for that time of day; and b) no date and day of week change is required. But still it can mess up things like logging. So in the fall, you could make a phone call at 1:45 AM and make one "later" at 1:15 AM. I don't know what would get logged if you made a call like that in the spring.
There shouldn't be any bugs in requiring an operator to change it, maybe an inconvenience. But as I started out saying, it makes a HUGE difference exactly what the application is.
Lou