Summer time correction for timer crossing time change applied twice?

[ronand]

DST is nothing to do with NTP. The receiver will change its clock to summer time regardless of NTP or internet access. NTP on its own is useless without the timezone correction.

[BrokenUnusableAccount]

Did it record properly or do you just want to fight with the world?

Yes they recorded correctly.

[ronand]

So its just a small matter of the recording times displaying in winter time then? For something that happens twice a year and the end result being a correct recording is it really worth staying up for?

[Joe_90]

I was actually watching World War Z at the time when Brian posted. I also had a recording in progress on Sky Arts (Eagles at the Forum 00:05 GMT - 05:00BST). It was flagged correctly as being of 175 mins duration. I also did an instant record of the remainder of World War Z and it initially showed in the timer as finishing at 03:15BST instead of the the EPG indicated time of 02:15. I presumed it to be some minor calculation error in the timer code. In any case it stopped recording at 02:15BST as I'm using the VPS plugin and the Eagles recording was correct also.

I was watching the clock at as it came up to 00:59:59GMT and it immediately switched to 02:00:00. So the timekeeping coding in linux would have kicked in as it knows that the DST switch happens at 01:00 on the last Sunday in March in most (all) of the European timezones. I presume this has nothing to do with enigma or NTP or transponder settings as the system clock would have been changed by the OS. Further time corrections would be done by NTP or transponder.

[birdman]

How does it automatically switch??

It doesn't.
The system clock always runs in UTC. There is never any correction to make (apart from the occasional leap second).
It is the display of the time that changes. Because the code that converts the UTC clock time into display text knows when DLST starts and stops for the time zone you are in and acts accordingly.

[ccs]

It doesn't.
The system clock always runs in UTC. There is never any correction to make (apart from the occasional leap second).
It is the display of the time that changes. Because the code that converts the UTC clock time into display text knows when DLST starts and stops for the time zone you are in and acts accordingly.

I think we've already established that.

[Joe_90]

I phrased it badly - birdman is correct that the system clock on linux systems always maintains UTC. The DST changes are handled by tz tables and displayed correctly at the appropriate time.

[BrokenUnusableAccount]

Yes they recorded correctly.

Oops. I was wrong.
Sorry about that.
World War Z recorded with an extra hour of the next programme on the end.
CNN Special Report recorded correctly.

Not what I was expecting/hoping.

I think this means there's more variables to consider.
It may depend on how the timer was created (from the EPG or by an autotimer).

I'm pretty certain I just pressed Green in the grid EPG to create the timer.

There's not really going to be a good way to investigate for another year.

[ccs]

I'm pretty certain I just pressed Green in the grid EPG to create the timer.

You didn't extend the timer by an extra hour because it would have been running across the 01:00 boundary?

It's the sort of thing I might have done, just in case.

[BrokenUnusableAccount]

There's not really going to be a good way to investigate for another year.

And, of course, there isn't going to be a similar problem either.

You didn't extend the timer by an extra hour because it would have been running across the 01:00 boundary?
It's the sort of thing I might have done, just in case.

No. I'm sure I'd remember.

[ccs]

There's not really going to be a good way to investigate for another year.

Having not thought this out at all, couldn't you change the timezone by +1 hour to see what happens, in a controlled way?

[birdman]

Having not thought this out at all, couldn't you change the timezone by +1 hour to see what happens, in a controlled way?

That's not going to leave you in a different offset at the opposite ends of the recording, which is what the issue depends on (in some way).

You could you for a DLST time change that occurs at a different time of the year and, if there is one, set that timezone for a test.

[ccs]

I do understand that I get things wrong, but if a recording is set to start at 00:45 until 02:15 last Sunday, based on the times, will it not record for just 30 minutes?

The only way round this is if the end time is actually defined as 90 minutes after the programme started, or some magic adjustment is made at 01:00?

[ronand]

Only 1 person has reported a problem. From what Brian has posted it seems the recording was 4 hours long but he will have to confirm that.

From his original post it seems the timer was set correctly - note the 189 minutes duration which was the published length of the program. Both the start and end times were in WINTER TIME which was correct at the start of the timer recording so there are no bugs there. Also his screenshot of the epg is correct showing the program ending at 2.17 SUMMER TIME.

[ccs]

Only 1 person has reported a problem. From what Brian has posted it seems the recording was 4 hours long but he will have to confirm that.

From his original post it seems the timer was set correctly - note the 189 minutes duration which was the published length of the program. Both the start and end times were in WINTER TIME which was correct at the start of the timer recording so there are no bugs there. Also his screenshot of the epg is correct showing the program ending at 2.17 SUMMER TIME.

I'm not suggesting there is a problem, I'm just trying to understand how it actually works in practice.