Daylight saving time change shifted my scheduled recording times

[calande]

Hello,

This week-end, where I live, we set clocks forward by one hour (daylight savings). The time change happened Sunday morning at 2:00am: When it used to be 2:00am, it is now 3:00am.
I had a program recording scheduled Sunday night (yesterday, after the time shift), at 9:10pm. Today, I noticed the recording started only an hour later than expected (10:10pm).

I tried to understand what may have caused it. I remembered the daylight saving time, and thought this may be related. I took a look at the TV Guide tab of the web interface of NextPVR: the vertical line of the time indicator properly indicates the current time (but I have no idea if this was the case yesterday).

However, I headed over to the "Scheduler" tab, and noticed that the start times of all my scheduled recurring recordings are all:

• set back by an hour in the "Pending" list (e.g. if a recording used to start at 9:05pm, it now reads "10:05pm")
  
• set forward by an hour in the "Recurring" list (e.g. if a recording used to start at 9:05pm, it now reads "8:05pm")
  

As a side note, I tested further: After scheduling a new recording by pressing the (+) icon, the new recording list item displays:

• the correct start time in the "Pending" list
  
• the wrong start time in the "Recurring" list (time is set back by an hour, now)
  

The clock of my NAS that hosts my NextPVR Docker container is updated properly and follows the daylight saving time properly (just confirmed).
I restarted by docker container, updated the Scheduler web page (Ctrl-F5), and the start times are still offset...
Have you ever faced this type of issue? Do you know what may be causing it?

Thank you.

[mvallevand]

The NextPVR web guide will show the wrong guide times after the change until the next day, so it should be ok today. NextPVR schedules by UTC so recordings should be correct.

I don't use manual recording since the guide based and timeslot rule work well for me but just tested one and it was ok. Did you check your browser timezone https://robots.net/software-and-applicat...-timezone/

Martin

[calande]

Thank you Martin, I just did one more test, I scheduled a recurring, 1 minute, recording.
And although the time is wrong under the "Recurring" list, it recorded properly, at the right time.
I just need to keep it in mind. It's not a big deal, it doesn't hinder the schedules.
Thank you.

[mvallevand]

Could you send the zipped logs from NextPVR, the time should be correct in the recurring list.

Martin

[SamM]

Could you send the zipped logs from NextPVR, the time should be correct in the recurring list.

Martin

I'm reviving this issue. I have noticed that every time there is a time change on/off DST, my recordings go an hour off. To get them back on the right schedule, the day after the time change I have to cancel all pending recordings and reschedule them. It has happened every single DST change, whether using EPG or manual scheduling. I'm only reminded to cancel and reschedule when I see that I've lost a recording because it's an hour off. It happened in March of this year when I was still using EPG, and it happened this time when I'm using manual recording.

The recording in question was the movie "MVP" on Houston OTA broadcast, channel 49.2 Bounce, which was set up to record Sun. 11/2 at 6:00 pm to 9:00 pm (3 hrs), which was scheduled on 10/30. The movie was to run from 6:10 until 8:45 pm. So the time stamp on the recorded file should have been 9:05 pm, since I set it for 5 min. overrun. But the time stamp on the file is actually 8:05 pm. Therefore, the recording started and ended an hour early.

So if this issue can't be fixed, then I will have to work around DST twice a year. Not difficult, but certainly inconvenient. Anyone with a suggestion?

[mvallevand]

What is your guide source? I actually don't see anything happening to change the guide data and it looks like the guide data showed one hour early.

2025-11-02 02:47:27.684 [DEBUG][8] Requesting wake up for 'RecordingOID6318' [MVP (2022)] at 11/2/2025 4:54 PM

Martin

[SamM]

What is your guide source?  I actually don't see anything happening to change the guide data and it looks like the guide data showed one hour early.

2025-11-02 02:47:27.684 [DEBUG][8] Requesting wake up for 'RecordingOID6318' [MVP (2022)] at 11/2/2025 4:54 PM

Martin

I'm not using a guide source, because since zap2xml no longer works, I decided to do manual recordings from now on, which started around July of this year.

Right, it's one hour early because the recording was scheduled on 10/30 to start at 6:00 (with 5 min. pre, 5 min. post). So it should have waked the unit at 5:54. But because the system clock was changed back an hour at 2am on 11/2, the recording started an hour early (and finished an hour early). This is the issue. Every recording that was scheduled before the time change gets skewed by 1 hour. The only solution is to cancel all the recordings and reschedule after the time changes.

I noticed this years ago, but it seldom happened (DST coinciding with scheduling), and I could usually get another date and time for that movie. Or, I remembered the problem and worked around it.

[mvallevand]

That is the problem then. Times in NextPVR are in UTC so if you set a manual recording before the timezone change, you have to factor in the new time in UTC you set the time, or create if after the change. Same with manual recurring recordings. Long time issue, but very few people use NextPVR without a guide.

Martin