Once again I have been tilting at the early DST change windmill. The problem happens (mostly) exactly one month prior to the scheduled change on most DFW area stations. (The ones I watch anyway.) This time around I was presistant enough so that a local station (the only one that ever responded) actually pushed this probelm upstream to their hardware provider.
I was amused at the response which was:
1) A correct implementation would work.
2) It can't be a serious problem because we haven't heard about it.
1 is obviously false to anyone who can read the ATSC specification. (annex A of A/65) The system time table provided in the OTA data stream includes the current date and time plus three values to control the DST switch. While the day of month and hour is provided, the month isn't. So when the station starts broadcasting the day of the change as being the 11th on 11 Feb. it should be expected that receivers will change on 11 Feb. (The error goes away on 12 Feb. because the DST status flag hasn't changed and the day of month no longer matches.)
2 is hilarious because it took a lot of persistance on my part before the local station forwarded my complaint to Triveni. It wasn't too hard to find threads here about this problem so it isn't the case that no one has seen it. It is just the case that complaints haven't filtered up to the hardware manufacturer.
But at this point Triveni appears uninterested in fixing what they perceive as a non-problem.
You're really late to this party - so let me give you the party line -
You're problem is probably caused by the firmware of your ATSC receiver (be it TV, DVR, set top box, whatever) not correctly intrepreting the code for DST.
Then please explain to me how a receiver is supposed to know you mean 11 March when you set day of month to 11 on 11 February?
From Annex A of A/65:
When the transition into daylight saving time is within less than one month,
the DS_day_of_month field takes the value day_in, and the DS_hour field
takes the value hour_in. The DS_status bit is 0 indicating it is not yet
daylight saving time. (The transition is to occur on the day_in day of the
month at hour=hour_in; for example, if the transition were on April 15 at
2:00 a.m., then day_in=15 and hour_in=2).
I have yet to see any PVR handle daylight savings time correctly.
At least on MythTV, it only screws up the wakeup time for the first recording after the transition, so one recording once a year (the other error has the system wake up an hour early, so it goes back to sleep and wakes up at the correct time. It is only when it wakes up an hour late that it screws up a recording).