I live in Southern California and I too find these things to be pretty flaky.
(They're more correctly called "radio clocks," btw. The real atomic clock they rely on is in Colorado!)
Unfortunately the WWVB signal is not very good at covering the entire country. NIST is considering adding another transmitter on the east coast. But it will be on a different frequency, so you'll need to buy new clocks to receive it. Probably they will make dual-frequency units.
In the meantime the best you can do is to make sure the clocks have fresh batteries and keep them in windows that face toward Ft. Collins, Colorado - i.e. to the west, if you're on the east coast (the exact direction is not critical). And try to keep them away from other electronic gear (which can interfere with the signal).
Me, I'm in a corner of a building and my windows face only west and south; Colorado is northeast of here. Bummer.
btw they are only supposed to sync once a night (reception is better at night). They do this to save battery energy. Even the ones that are plugged in usually do this as they usually use the same firmware as the battery-op models. (Lazy manufacturers.) However if they don't sync on the first try they are supposed to try a few times per night. If they aren't set at all, they don't know when it's night, so they just try a couple of times per hour or so until they sync.
You could try forcing a resync by taking the batteries out (or unplugging) and putting them back in - or if the clock has a "receive" button, try that.
Re the DST change, it doesn't help that WWVB only gives a short advance warning. The "DST changes today" code shows up in the time code at 0000 UTC on the day of the change - which, if you're on EST, is 1900 local. And the clock needs to "spring forward' at the very next 0200 local, just seven hours later. So if your clock doesn't happen to sync sometime in those seven hours, it will not have seen the "DST changes today" indication and so will not "spring forward" at the right time.
It will, however, change to DST the next time it syncs after that, as the code changes to "We're on DST now" at the next 0000 UTC, and stays that way until fall. The clock will follow that even if it missed changing at the exact right time.
In the fall the code goes through the same sort of cycle, going to "DST changes today" at 0000 UTC the day of the change, and changing to "we're not on DST now" at the next 0000 UTC. Notice that in the fall, we get an hour *less* warning of the coming change.