My stations sometimes mess up in the Fall, but usually they do better with the Spring DST change.
The PSIP datastream has room to enter 'day' of change, but not the month. A station can enter the day up to a month early, but not until after that day has passed in the month prior to a change. Last Fall, 2 stations entered the "6" flag prior to 10/6, and I had 3 bad times for recordings on 10/6 and 10/7. The stations fixed their time, but however the Pal handles such changes, the recordings ended up being adjusted twice, so they were off by two hours, instead of just one. All other timers in the guide were ok, and it wasn't until 2 weeks later when more bad times showed up that I realized the Pal treats long term weekly timers differently than near term timers (with attached dates). A number of long term timers (represented on the timer list by the 'double circle' repeater symbol) had been flagged "STD" and as they appeared in the guide, the times were all off. That double whammy is why some say just dump it all and start over after the time change.
There seem to be additional mysteries with time changes. Last week, I added a weekly timer for early Sunday morning, setting the recording from the guide. I checked later in the week and everything looked ok. But Saturday, I noticed that the time was not right. I checked the guide and saw the program info had changed, my program was no longer on. That wouldn't explain why the timer got changed, or why the scheduled recordings list showed a second channel due to record at that same odd time, and I'm sure I didn't set a timer for that channel. It just appeared with that same odd time.