Daylight savings time ends on 3 November which means that stations should begin sending PSIP data to that effect on 4 October. The details on how this process should be managed are in ATSC A/65, Annex A and FCC regulations require that all except low power stations follow the standard. But they have a poor record of following the standard.
Today is when the process should begin with data for day of month and hour changing to "10" and "3". Beginning the transition early causes any receiver that uses this data to think that 3 October is the day to switch to DST. When the DS_status flag doesn't change, time returns to normal on the 4th.
Data in the plots begins at midnight on the morning of the 2nd.
As is all too common, there were early birds. KAZD at 2AM on the third and KDTX and 9PM. Late in the day is just as wrong as early.
KAZD (RF 31)
KDTX (RF 21)
Then a few starting on time:
KTXA (RF 18)
KXAS (RF 24)
KDFI (RF 27)
KDTN (RF 29)
KUVN (RF 33)
KDFW (RF 35)
KXTX (RF 36)
A few decided to be a day late.
WFAA (RF 8)
KERA (RF 14)
KTXD (RF 23)
KPXD (RF 25)
KFAA (RF 30)
Really late is KFWD:
KFWD (RF 9)
Usually most of the mistakes were made early in the process but there were plenty of them made today. First up is KHPK. They gave the whole DST thing a miss. With a DS_status showing standard time and of course skipping the day and hour of change. But at 2AM (CDT) they shifted the time data by an hour.
KHPK (RF 10)
Next up is KERA, the local PBS station, who for some reason decided that 1AM was the time to switch out of DST.
KERA (RF 14)
Then we have KDTX who dropped the day and hour data at 9PM while switching DS_status at 2AM.
KDTX (RF 21)
Plus of course KFWD. They waited till the 1st to even bother with setting the day and hour data so it is no suprise that they didn't complete the process on time.
KFWD (RF 9)
Some stations completed the change at 2AM as expected. Since DFW is nowhere near a time zone boundary, the broadcast area changes out of DST at 2AM. A few waited till later. 4AM being very popular. Not correct but not a disaster.
This is very creative:
KDTN (RF 29)
Given what their time data is doing at the same time, this appears to be the result of switching from primary PSIP hardware to a backup. And back again. With the backup hardware having different settings.
This long after the digital transition something as simple as the correct handling of daylight savings time shouldn't be this error prone. Two additional problems are KTVT and KDAF who never bothered with DST transition data and are still indicating a status of in DST.
KTVT quietly dropped DS_status this morning. Late and without bothering with all of that preliminary day and hour stuff as required by ATSC standard A/65.
KTVT (RF 19)
I used the viewer contact form on the KDAF web site to tell them about their DST problem. Amazingly I got a reply. Not so surprisingly it claimed all was well and that their PSIP hardware handled DST automatically. Shortly before that email was sent...
KDAF (RF 32)
Since I no longer have the space limitataions with my Earthlink pages I can make data from previous transitions available here rather than rely on the Internet Archive.
2015 | spring | fall |
2016 | spring | fall |
2017 | spring | fall |
2018 | spring | fall |
2019 | spring | fall |
2020 | spring | fall |
2021 | spring | fall |
2022 | spring | fall |
2023 | spring | fall |
2024 | spring |