But the crux of Frank43's current problems is Daylight Saving Time. Neither a more accurate local clock nor Internet time servers would deal with DST.
One way to deal with DST is through the use of fixed rules. This is the approach Windows, for example, takes; however, it requires an update any time some country changes their DST rules.
In 20-20 hindsight, simply providing Pal owners a 3-way DST choice: no DST, April-October DST, or March-November DST, would've worked just fine. As it happens, the US and Canada have used the March-November schedule since 2007, about the same time the Pal was being designed, and Mexico (except border towns) uses the April-October schedule, so if the Pal had gone this route, it would never have needed an update.
But, not knowing the future, there was always a chance any of these countries could've changed their DST schedule at any time, so E* chose instead to rely on the stations sending accurate DST change info. Unfortunately, that's proven to be a disaster, both for Frank43 and for those of us who have to suffer through a 1-day DST foul-up one month before every actual DST change. Turns out station-provided info isn't so reliable after all.
In the US, there was another possibility: WWVB could've been used to provide both accurate time and a guaranteed-correct DST schedule. An LF receiver on the circuit board and a cheap loopstick antenna plugged into the back of the Pal would've been the only extra hardware needed. But Mexico and Canada don't have an equivalent to WWVB. (Canada does have some shortwave stations similar to WWV in the US, but having to connect a shortwave antenna to your DVR is probably asking a bit too much