Menu
▾
▴
#51 DST end problem
There is a time slip in the output xml file. All times (as far
as I can tell) are offset one hour into the future since we
went from DST to standard time (CET). Here is some
example output from the file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE tv SYSTEM "xmltv.dtd">
<tv source-info-url="http://www.dagenstv.com/"
source-data-url="http://www.dagenstv.
com/se/frontpage" generator-info-name="XMLTV"
generator-info-url="http://membled.
com/work/apps/xmltv/">
<programme start="20031028012500 CET"
showview="9357935" channel="26.dagenstv.com">
<title>Saturday night live</title>
<desc>Amerikansk underhĺllning frĺn 2000-01. Gäster:
Dana Carvey och The Wallflowers.</desc>
</programme>
And here is the relevant information from dagenstv.com
(the target site for tv_grab_sn).
---
00:25
Saturday night live
Amerikansk underhĺllning frĺn 2000-01. Gäster: Dana
Carvey och The Wallflowers. [9357935]
---
I have tried regenerating the tv_grab_sn.conf but it made
no difference (and should not I think since no time-zone
info is stored in it.
Logged In: NO
Yes this problem exists.
This is from the file TVdata.xml before we turned back the
clock one hour:
"20031020161500 +0200"
After:
"20031027144500 CET"
But - before we turned back the clock, we also was in CET
timezone.
Something is wrong here.
/monshi
Logged In: YES
user_id=896459
Similar problems with tv_grab_fi, except that the time
offset in the xmltv listing compared to the source is 2 hours:
</programme>
<programme start="20031028132000 EET" stop="20031028142000
EET" channel="2.katso.fi">
<title lang="fi">YLE Teema:Tiedefoorumi</title>
<desc lang="fi">Mist tulevat suomalaiset? Idst vai
lnnest? Suomalaisten alkuper puhuttaa. Studia Generalia
-tapahtumassa luennoivat professori Jorma Koivulehto ja
Anna-Leena Siikala.</desc>
</programme>
--------
source material (www.katso.fi):
11:20 YLE Teema:Tiedefoorumi
Mist tulevat suomalaiset? Idst vai lnnest?
Suomalaisten alkuper puhuttaa. Studia Generalia
-tapahtumassa luennoivat professori Jorma Koivulehto ja
Anna-Leena Siikala.
--------
Time on the machine doing the grabbing is stored in local
time and is currently correct for Eastern European standard
time.
Logged In: YES
user_id=896459
the error is definitely in parse_eur_date() in
XMLTV::Europe_TZ :
114 elsif (Date_Cmp($dp, $end_dst) < 0) {
115 # During summer time.
116 return Date_ConvTZ($dp, $summer_tz, 'UTC');
117 }
118 elsif (Date_Cmp($dp, $end_dst_backfrom) <= 0) {
119 # warn("$date is ambiguous "
120 # . "(clocks go back from $end_dst_backfrom
$summer_tz to $end_dst $winter_tz), "
121 # . "assuming $summer_tz" );
122
123 return Date_ConvTZ($dp, $summer_tz, 'UTC');
124 }
125 else {
126 # Definitely after the end of summer time.
127 return $dp;
128 }
at this time of year we fall into the last case which is
returning an unparsed date, whereas the intention seems to
be to return the date in UTC, I think. If that is truly the
case, then that case should probably return something like
Date_ConvTZ($dp, $winter_tz, 'UTC') .
Logged In: YES
user_id=896291
avidday, if I understand you correctly that means that for
winter/standard time every grabber using XMLTV::Europe_TZ
will default its times to UTC (which is GMT standard time right?
). This would also confirm the finnish problem.
Who should I reassign this bug report to for updating the
relevant code?
Logged In: YES
user_id=896459
tv_grab_fi and tv_grab_sn seem to use parse_eur_date() as in
the following snippet:
350 my $cur_time = $cur->{time};
351 my $start=parse_eur_date("$date $cur_time", $TZ);
352 my ($start_base, $start_tz) =
@{date_to_eur($start, $TZ)};
353 $prog{start}=UnixDate($start_base, '%q') . "
$start_tz";
ie. they call parse_eur_date() to determine whether a raw
listing date/time is in summer or winter time and give them
a date/time value in UTC which is then re-encoded into the
right time format using date_to_eur(). So the correct
functionality relies on parse_eur_date returning the
date/time in UTC coordinates. Whether that is the exact
intention of parse_eur_date(), I have no idea.
In summer this is exactly what happened. parse_eur_date
returns a UTC formatted value via
114 elsif (Date_Cmp($dp, $end_dst) < 0) {
115 # During summer time.
116 return Date_ConvTZ($dp, $summer_tz, 'UTC');
117 }
Now we are in winter time parse_eur_date returns an
unconverted value via:
125 else {
126 # Definitely after the end of summer time.
127 return $dp
128 }
So the behaviour in parse_eur date() is inconsistant. In
summer it appeared to return a UTC value, now it returns a
value in whatever time coordinates the raw listing was in.
Hence in tv_grab_fi we now see times being out by +2 hours,
ie. the time difference between UTC and EET.
Which is case is wrong depends totally on what exactly
parse_eur_date() is supposed to do -- just from reading the
XMLTV::Europe_TZ code, I am not sure. I only started using
XMLTV last thursday, I had never looked at the code until a
couple of hours ago and I have never done any serious perl
programming before. One of the developers is surely better
qualified to answer it than I am.
So the answer probably some combination of the following
possibilities
(a) grab_tv_fi and grab_tv_sn are misusing the
parse_eur_date() function
(b) parse_eur_date() is broken for summer time and
grab_tv_fi and grab_tv_sn relied on the summertime bug to work
(c) parse_eur_date() is broken for wintertime and is
breaking grab_tv_fi and grab_tv_sn as a result.
Your guess is as good as mine as to what to do to fix it. I
hacked my local copy of parse_eur_date() to work for the
winter case the same way as it worked for the summertime
case, thereby given me a working TV listing until the end of
March 2004, by my reckoning. What is the "right thing" to do
to fix it, with respect to the other european tv_grab apps I
will leave for someone of greater talent than I to resolve.
Logged In: YES
user_id=896291
Ok, I think you're right avidday, it appears to me as the
parse_eur_date() is not consistent in its output. If it is
intended to always be used with a timezone modifier as well it
shouldn't allow usage without it as it is now.
Mind you I have never done any perl programming at all but a
few other languages.
I'm reassigning this to epaepa to solve since he seems mostly
responsible for the module.
Logged In: NO
Any guess when this issue will be resolved for users like me
who doesn't have the knowledge to go into the code of the
project and correct it temporarly?
/Monshi
Logged In: YES
user_id=896291
Monshi:
No idea. It all depends on when Ed (epaepa)decides to surface
and look at this problem. If you're using the precompiled
windows version it might be a while before a new version
comes out officially.
Please tell us which grabber you use so we can see if the
problem affects more than the already "confirmed" ones (sn
and fi).
It'd have to be a developer in the project that should fix this
bug but apparently they aren't very active. There should be
tests run to confirm the changed code as well so it's not as
easy as just altering the code.
Logged In: NO
Using tv_grab_sn.conf bundled with TVHolic
Can report that in UK eveything works as expected, at least
according to someone behind the username DeBugger.
/Monshi
Logged In: NO
The problem also applies to tv_grab_dk:
A program starting at 21.30 has the following start time in the
XML-file: "20031028223000 +0100".
Regards,
Thomas
Logged In: YES
user_id=790698
One suggestion in connection with the fix: Have the program
avoid using "CET" for the timezone, and use "+0100". Some
applications (ie the myHTPC EPG) do not correctly
parse "CET".
/Per
Logged In: YES
user_id=10769
Thanks everyone for reporting this and especially avidday
for spotting the problem. parse_eur_date() did not
correctly handle the winter timezone case, it assumed the
winter TZ was UTC. That's why the UK grabber worked but all
the others were out.
I have checked in a fix and will make a new release with it
soon, in the meantime you can get an updated Europe_TZ.pm as
<http://membled.com/work/apps/xmltv/cvs_working/grab/Europe_TZ.pm>.
Logged In: YES
user_id=10769
On the question of whether the output should have 'CET' or
'+0100' , I have opened a separate bug report, #834143, to
track that. Please add yourself to that bug report if
you're interested.
Logged In: YES
user_id=896291
I have verified an early version Windows binary of 0.5.20 to
having solved the time slip problem. The CET issue remains
though but is adressed in a separate bug report.