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

[BrokenUnusableAccount]

Look at timer for "World War Z" in the timer list.

Surely if the code displaying the timer was just ignoring tonight's time change it would show as ending at 01:17.
If it was corrected it would show as 02:17 (the actual time it ends after the time change).
But it actually shows as ending at 03:17, as if correction has been applied twice.



Weirdly "CNN Special Report" further down looks correct.

I will check tomorrow to make sure they actually recorded correctly.

 

[birdman]

Look at timer for "World War Z" in the timer list.

Surely if the code displaying the timer was just ignoring tonight's time change it would show as ending at 01:17.

But it isn't ignoring it. there is no 01:17 tonight.
The times are stored in Epoch time (seconds since 01 Jan 1970) and Linux knows how to display these in your timezone (unlike MS Windows...).

If it was corrected it would show as 02:17 (the actual time it ends after the time change).
But it actually shows as ending at 03:17, as if correction has been applied twice.

Perhaps it has, as the duration show >3hrs, for a 116m minute file + ads.

Weirdly "CNN Special Report" further down looks correct.

Might be a result of it starting and ending n the same day, which WWZ does not.

I will check tomorrow to make sure they actually recorded correctly.

Recording an extra hour at the end still sounds "OK" to me.

 

[BrokenUnusableAccount]

If you're not actually interested in whether it's working correctly why bother to reply at all?

 

[ronand]

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

 

[cactikid]

Totally lost as getting up this morning feel like an hour behind the scenes
Must check timers to see if they have changed or if any are set.

 

[ronand]

Any future timers should be fine as long as the epg data was correct in the first place (and that seems to be the case)

 

[ccs]

British summer time officially started at 01:00 this morning, so hadn't kicked in when the snapshots in post #1 were taken.

When selected, NTP runs periodically, so will advance the time by 1 hour some time after 01:00 ??

If you're using transponder time, then I'd guess the time will change at 01:00, but that is clearly still dependent on the broadcasters.

I use transponder time, but there is still a cron job which runs ntpupdate every 30 minutes.

 

[ronand]

Its nothing to do with ntp or transponder time - the system automatically switches to Summer Time at 1am to 2am. The film was 3 hours long including ad breaks so the timer was set correctly. At 1am the recording end time should have changed to 2.17 but as it seems the displayed time did not reflect this although I am pretty sure the recording did finish at 2.17 SUMMER TIME. We will have to wait till Brian clarifies this.

 

[ccs]

Its nothing to do with ntp or transponder time - the system automatically switches to Summer Time at 1am to 2am.

How does it automatically switch??

 

[ronand]

Summer/winter time switching is implemented in most devices with a clock nowadays. My watch and phone both changed by themselves and internet access was disabled on both. Once DST is enabled in a device it will change. Internet is not required. European Summer Time begins at 01:00 UTC/WET (02:00 CET, 03:00 EET) on the last Sunday in March and ends at 01:00 UTC (02:00 WEST, 03:00 CEST, 04:00 EEST) on the last Sunday in October each year.

 

[ccs]

.... so how do I set up a ViX box to "automatically switch" to BST ?

 

[ronand]

Just set your timezone correctly

 

[ccs]

Just set your timezone correctly

So NTP uses the timezone to set the correct time?

 

[ronand]

Indeed it does. NTP uses UTC (it is global) - so the timezone offset set by the user is needed to set the correct time

Edit: Maybe I should have said that NTP uses UTC - the receiver or any other device using a NTP server uses the timezone offset to get the correct local time.

 

[ccs]

So when you said "Its nothing to do with ntp or transponder time...", it actually is.

 

[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.