Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[Zgemma H7] Summer time correction for timer crossing time change applied twice?

  • Thread starter Thread starter BrokenUnusableAccount
  • Start date Start date
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.:)
 
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.
 
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.
 
Last edited:
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.
 
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.
 
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?
 
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.
 
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?
 
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.
 
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.
 
FWIW, here's what happens to a timer when the clocks go forward an hour (London => Berlin).
 

Attachments

  • lon.webp
    lon.webp
    14.9 KB · Views: 16
  • berlin.webp
    berlin.webp
    14.9 KB · Views: 16
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.

As far as I'm aware "World War Z" was scheduled to start on Saturday at 23:10GMT and finish on Sunday at 02:15BST.
That's a length of 2 hours and 5 minutes, or 125 minutes.

The recording was 188 minutes long, made up of 185 minutes plus some extra pre and post gaps I always add.
(That's 2 minutes pre and 2 minutes post extra time that seems to only make the recording show as 3 minutes longer than scheduled, but I assume it's actually just a fraction short of 4 minutes longer).

I did check the recording and, yes, there was an hour of the next program on the end after WWZ finished.
 
Last edited:
As far as I'm aware "World War Z" was scheduled to start on Saturday at 23:10GMT and finish on Sunday at 02:15BST.
That's a length of 2 hours and 5 minutes, or 125 minutes.

The recording was 188 minutes long, made up of 185 minutes plus some extra pre and post gaps I always add.
(That's 2 minutes pre and 2 minutes post extra time that seems to only make the recording show as 3 minutes longer than scheduled, but I assume it's actually just a fraction short of 4 minutes longer).

I did check the recording and, yes, there was an hour of the next program on the end after WWZ finished.

What was the actual length of the recording - 188 minutes??
 
...... deleted.
 
Last edited:
Then it recorded correctly. If the movie is only 2 hours long thats not a fault of Openix. So there is no recording bug then.

Code:
www.tvguide.co.uk/detail/1856765/44370300/world-war-z-2013
 
Last edited:
Then it recorded correctly. If the movie is only 2 hours long thats not a fault of Openix. So there is no recording bug then.

Code:
www.tvguide.co.uk/detail/1856765/44370300/world-war-z-2013

For some bizarre reason that I can't even begin to imagine you're ignoring the fact that I didn't click on tvguide.co.uk to set the timer.
I did it in OpenViX, from the EPG there.
I can't really see why you think pointing out that some other random TV guide got it wrong is relevant.

Other, less brain dead TV guides correctly say it is 2 hours 5 minutes long.
WWZDG.webp WWZDGc.webp

I wish we could upload full HD images here and not have it reduced to a silly low resolution jpeg.
 
Last edited:
I rarely look at tv guides - it was the first one that came up. Anyway you may stay up late to watch your recordings in october - you will probably lose a hour of them instead.
 
Actually I was assuming this meant it was the correct length in the EPG on my box:
OVCalCorEpg.webp

But come to think of it, that's probably not necessarily the case.
I might just look the right length because the next program is over the top of the end of it.

Is that what you were pointing out ronand?
 

OpenViX Feeds Status

Back
Top