Bug 354522 - repeated recordings get time-shifted by daylight-saving-time switches
Summary: repeated recordings get time-shifted by daylight-saving-time switches
Status: RESOLVED FIXED
Alias: None
Product: kaffeine
Classification: Applications
Component: general (show other bugs)
Version: 2.0.1
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Mauro Carvalho Chehab
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-28 19:04 UTC by M G Berberich
Modified: 2017-03-26 19:28 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
fix dst switch problem (692 bytes, patch)
2016-10-28 17:26 UTC, Nils Kassube
Details

Note You need to log in before you can comment on or make changes to this bug.
Description M G Berberich 2015-10-28 19:04:37 UTC
Planned recordings with repetitions get shifted 1 hour if daylight-saving-time ends.

Assumption: kaffeine saves the date+time as UTC and the conversion from UTC to localtime changes when DST gets (in)effektiv.

Reproducible: Didn't try
Comment 1 Mauro Carvalho Chehab 2016-06-27 21:46:52 UTC
I did several tests here with Kaffeine 2.0.3 and didn't notice any problem with DVB life view and changing the system clock. I even did instant records and paused/played the stream a few times, without noticing any problems.

As this bug was reported against a version we're no longer maintained, and version 2.0.x has huge changes since version 1.2.x, I'm closing this bug.
Comment 2 Mauro Carvalho Chehab 2016-06-27 21:54:11 UTC
(In reply to Mauro Carvalho Chehab from comment #1)
> I did several tests here with Kaffeine 2.0.3 and didn't notice any problem
> with DVB life view and changing the system clock. I even did instant records
> and paused/played the stream a few times, without noticing any problems.
> 
> As this bug was reported against a version we're no longer maintained, and
> version 2.0.x has huge changes since version 1.2.x, I'm closing this bug.

Please ignore this comment. It was meant for another BZ. Re-opening it, as I didn't check if this issue still happens on version 2.0.x.
Comment 3 Nils Kassube 2016-10-28 17:26:34 UTC
Created attachment 101858 [details]
fix dst switch problem

I can confirm the problem with the git source of today. The attached patch fixes it for me.
Comment 4 Cantoliv67 2016-10-30 07:36:56 UTC
I have the same problem.. 
I'm in west Europe (Belgium). 
on oct 30th, 3:00 am becomes 2:00 am. 
Kaffeine was running all night long. 
The system clock shift correctly at 3am -> 2 am. I was there to see it.
This morning, i have recording starting at 9:00 am. It become 8:00 am
And the start time of each recording become H-1:00... (11am -> 10am)

I already change the start times manually.. 
It would be fine that the start time stay unchanged on DST change.

Next DST change in Europe on the last sunday of march (March 26th, 2am -> 3 am).

Thanks to solve it before.
Comment 5 Mauro Carvalho Chehab 2016-12-27 17:45:17 UTC
(In reply to Nils Kassube from comment #3)
> Created attachment 101858 [details]
> fix dst switch problem
> 
> I can confirm the problem with the git source of today. The attached patch
> fixes it for me.

Patch applied:
    https://commits.kde.org/kaffeine/70234c78bccd8c6e34ff6357c134d3c5f26b39f1
Comment 6 Isence XEXEDI 2017-03-26 13:16:08 UTC
in which kaffeine release will this fix be available ?
this bug is still there in the current 1.2.2 version. in Europe, the DST shift appears the last sunday of march at 00:00 UTC. this took place this night, from 2017-03-25 to 2017-03-26 (from 02:00 to 03:00 in france). every weekly recordings ended from 2017-03-19 to 2017-03-25 are renewed this week from 017-03-26 to 2017-03-31 1 hour too late, as if the new date&time was wrongly added with 24x7 hours.
Comment 7 Mauro Carvalho Chehab 2017-03-26 17:17:19 UTC
(In reply to Isence XEXEDI from comment #6)
> in which kaffeine release will this fix be available ?
> this bug is still there in the current 1.2.2 version. 

Version 1.2.x are really old (2015)! It is not maintained upstream anymore. You should either upgrade to a newer version/distribution or request your distribution maintainers to backport the fixes (with may not be an easy task, as Kaffeine code changed a lot since version 1.2.x).
Comment 8 Nils Kassube 2017-03-26 17:21:54 UTC
The difference to the original patch is only an offset of several lines, so it should be easy to backport. If you are willing to compile from source, I could provide the necessary patch for 1.2.2.
Comment 9 Mauro Carvalho Chehab 2017-03-26 18:56:10 UTC
(In reply to Nils Kassube from comment #8)
> The difference to the original patch is only an offset of several lines, so
> it should be easy to backport. If you are willing to compile from source, I
> could provide the necessary patch for 1.2.2.

Yes, the difference on this particular patch is not big. Backporting shouldn't be hard. You should take some care, though, as Kaffeine 1.2.x, uses Qt4, kile Kaffeine 2.0.x uses Qt5. The Qt5 port had to change calendar and date handling on several places, due to differences on how Qt5 handle locales.
Comment 10 Mauro Carvalho Chehab 2017-03-26 18:57:26 UTC
(In reply to Mauro Carvalho Chehab from comment #9)
> (In reply to Nils Kassube from comment #8)
> > The difference to the original patch is only an offset of several lines, so
> > it should be easy to backport. If you are willing to compile from source, I
> > could provide the necessary patch for 1.2.2.
> 
> Yes, the difference on this particular patch is not big. Backporting
> shouldn't be hard. You should take some care, though, as Kaffeine 1.2.x,
> uses Qt4, kile Kaffeine 2.0.x uses Qt5. The Qt5 port had to change calendar

s/kile/while/

> and date handling on several places, due to differences on how Qt5 handle
> locales.
Comment 11 Nils Kassube 2017-03-26 19:28:28 UTC
Actually the patch was previously made for 1.2.2. Later I checked it with the current git source and made a new diff with the new line numbers. I have just tried the patch with the 1.1.2 source and it works directly.