dk.timefor.tv DateTime problem

Is working with the latest beta,

So try to use that one. I don't know if it should work under V55.27.
I think the @MinSWversion of this siteini should be set to V56.08 (but not sure). Jan could elaborate on that.

Bottom line, using the latest beta and you will be fine.

If you need V55, you should add

index_start.modify {calculate(format=utctime)}

to the siteini and it will also work.

It is just because the new beta "understands" the unix time stamp that is used by this site. But don't know when this feature was introduce exactly.

Fixed new version online.

I think you can change (in the siteini)

actor.modify {remove(type=regex)|(</strong><br>.*)} * remove any actor role (after the </strong><br>)

into

actor.modify {remove(type=regex)|<[^>]*>}

Currently this will be as close as you can get.
WG++ doesn't (yet) supports the role feature of xmltv.

No, the sitetimes are in UTC, so keep that.
1. Is that htpc computer set to the right local timezone (inc DST)?
2. When do you see the time difference? On the EPG viewer of your mediacentre?
3. Are the times in the xmltv file different from the ones on your work pc?

If the answers are 1. Yes, 2. EPG viewer 3. No  ,
then your problem is that the xmltv importer of your Media Center doesn't handle the timezones correctly (Happens alot !!) Which MediaCenter/xmltv importer are you using?
In case it interest you , read http://www.webgrabplus.com/content/times-time-zones-and-dst-corrections.

As a fix you can use either your solution utc+01:00 or http://www.webgrabplus.com/sites/default/files/download/utility/xmltv_time_correct/xmltv_time_correct.zip

Jan

Well, YES Xepg should the +0100 (or +0000 in this case) into account. Only if your computer is in the same timezone as your siteini, you could leave it out I think.
When DST happens, the +0100 will be adjusted to the correct value after the DST,so +0200. And your guide will be then 2 hours off.

So if you are the author of Xepg, it shouldn't be that difficult to add the time diff to the dst time. The actually thing you should do to make your importer robust/correct, is to read the time in the xmltv file eg. 20151115214500 and apply the UTC offset (eg. +0100, in your case it is only +0000). So the time you should get is then 20151115204500 (this is the actual time in UTC). And if you have the time in UTC, you have to convert it to the timezone of the current computer.

In short:

It should be:

(xmltv) 20151115204500 +0000  ==> (UTC) 20151115204500 ==> (local timezone) 20151115214500 +0100

The reason why you didn't had any issues with it, is that the timezone of the site (=siteini) was probably always the same as your pc.

(xmltv) 20151115214500 +0100  ==> (UTC) 20151115204500 ==> (local timezone) 20151115214500 +0100

And if you can see, because the first and the last are the same, you can "skip" the correct conversion, without having any issues. So that is why you didn't see any issues before I presume.

Hi

Francis already explained what an xmltv importer should do wrt timezone, dst and xmltv offset. Since you are the author of Xepg I recommend to read article http://webgrabplus.com/content/times-time-zones-and-dst-corrections
Because I suspect that Xepg handles timezones the wrong way (forgive me if I am wrong!) I will explain in depth how it should be done and why .

1.  xmltv times are always in UTC!! That is very important to keep in mind. Example
   20151115214500 +0100  must be interpreted as 2015/11/15 21:45 in a zone with an actual timeoffset of 1 hour wrt UTC, so in effect this xmltv time is 20:45 UTC.
   This is important because in this way , and by definition, the xmltv times are valid everywhere in the world, independant of local timezones and dst rules!!
2. Consequently, the +0100 above is a timeoffset and must not be confused with timezone UTC+01:00 !
3. As the article explains, this xmltv offset is provided by the xmltv creator, in our case WG++. It does this by grabbing the timedata from the tvguide site and calculate the required timeoffset to get the result in UTC as the definition requires.
   (in most cases, the times on the tvguide site are local times with dst rules applied. In that case WG++ has the difficult task to convert the time back to UTC by calculating the actual local UTC offset and the actual dst correction in it. In this case the timeoffset will change if dst changes)
   (in some other cases, like in dk.timefor.tv, the times on the site are already in UTC, easy , WG++ applies a constant +0000 timeoffset)
4. Because the xmltv times are in UTC by definition, the task to convert that into the correct time for the location of the user, can only be done locally! There come your Xepg xmltv importer into action.
   This should do the following:
   - Calculate the UTC time by subtracting the xmltv offset.
   - Determine the actual local UTC offset from the users computer (that is why it is important the the user has set the computer to the local timezone with dst enabled!!) and correct the UTC time for it.
   In simple terms ..       xmltvtime - xmltvtimeoffset + actual local UTC offset
5. Some examples
   a. xmltv :20151115214500 +0100, user in Denmark.
   subtract the timeoffset :  2015/11/15 21:45 - 01:00 = 2015/11/15 20:45
   add the actual local UTC offset (01:00 in November)  2015/11/15 20:45 + 01:00 = 2015/11/15 21:45
   This is the most common situation, the site has its times in local time and the user lives in the same location.
   b.  xmltv :20151115214500 +0100, user in Canary Islands (like me)
   - subtract the timeoffset :  2015/11/15 21:45 - 01:00 = 2015/11/15 20:45 , same as with a of course, xmltv times are 'global'
   - add the actual local UTC offset (00:00 in November)  2015/11/15 20:45 + 00:00 = 2015/11/15 20:45
   This is correct because if I want to see a show that occurs at 21:45 in Denmark, it is 20:45 here!
   This example works for every location in the world!
   c.  site times in UTC, like with dk.timefor.tv:
   xmltv :xmltv :20151115204500 +0000
   - subtract the timeoffset :  2015/11/15 20:45 - 00:00 = 2015/11/15 20:45 , same as with a and b of course, xmltv times are 'global'
   - rest as a. or b.

   I suspect that Xepg only works correct in case a. It assumes that the xmltv timeoffset is also the actual local UTC offset.
   I hope that you will correct the Xepg importer if that is needed.
   Francis and me always have great difficulty to explain that if WG++ has its times correct the user still find them offset in the epgviewer.
   Very recently I had an exchange of confusions with a WG++ user Andreas (I can send you his mail address if yoy want) which uses Xepg. He didn't want to believe that the error was with Xepg

   You can also try our own viewer http://www.webgrabplus.com/sites/default/files/downloads/Misc/EPGEdit1.4.zip to demonstrate the effect of the method described above. You can even experiment with the source code if you like.

   Jan

   P.S. Parts of the discussion with Andreas:
   ME: Basically there cannot be a date error anymore because the date is the date of the epg data of the site . The time in UTC is now presented with timeoffset +0000. So in the output xmltv you will see 20152910012000 +0000.
   Now how will you get the correct time in your epg viewer. Assuming you live in Denmark , now UTC +01:00 (wintertime) (but in fact it is not essential, because it works in all timezones in the world), and with your computer set to the local timezone, your viewer or your Mediacenter will correct the xmltv time for the timezone of your computer. The xmltv importer of that should take care of that. If it doesn't, its an error of that xmltv importer!!
   (Some importers do not handle the timeoffset in the xmltv correctly or ignore them all together). You can check if it performs correctly if there is the time in the epg viewer are one hour later than the one in the xmltv and of course the same date. If it interest you also read http://webgrabplus.com/content/times-time-zones-and-dst-corrections

   If you have such a bad behaving xmltv importer you can use http://webgrabplus.com/sites/default/files/download/utility/xmltv_time_correct/xmltv_time_correct.zip to offset the times in the xmltv.

   And me again:
   Your xmltv is still made with the wrong timezone setting. It must be UTC !! That results in the listing as above, eg 11:50 UTC (20151030115000 +0000)  for Hammerslag 2008, which is 12:50 in Danmark. As explained before the conversion from UTC to local time is always done by the xmltv importer. See my example with the xmltv importer of our own viewer. But I can assure you that the xmltv importer for Windows Media Center (e.g. Big Screen EPG) does exactly the same. If yours doesn’t, its wrong!!

And :
Some more explanation. The latest version of dk.timefor.tv.ini gets the times directly from the website, complete, date and time. In that mode (there is also another one, described below) the program doesn’t manipulate or recalculate or shift these times at all! All the times in the xmltv are the ones it got from the website. So if there is an irregularity in the xmltv time then the same irregularity is in the times given by the site! You may react by saying that that can’t be true because there aren’t any irregularities on the front page epg view. But it can because this site lists its times twice, once as the time it uses to display on the front page epg viewer and another as unix time.

This is part of how a show is listed in the website epg data page:

<td class="time"><p>04:10:</p></td>

  <td class="title"><p><a href="http://webgrabplus.com/i/120501446952200-mord-centrum" class="programsummary" programid="120501446952200">Mord i centrum</a></p></td>

The first 04:10 is the display time, without a date

The second is the unix time 1446952200 which after conversion is Sun, 08 Nov 2015 03:10:00 GMT

As you will notice the Unix time is in GMT (UTC) and is one hour earlier (which is correct)

What I am saying is that there might be a mistake in one or the other time now and then! It won’t be the first time that such happens.

But there is a second time extraction in WG++. That was used in the previous version of the ini. That used the first time, 04:10, without a date. So WG++ has to add the date . It does that by assuming that the first grabbed show has its starttime ‘today’. Then it must track the time to pass midnight, to add one day to the date. This is a rather tricky procedure which is not fully fault proof.

I have a problem with start and stop time. I run grabber now. Now timestamp is "1511039095000". and it grabs programs with timestamp "20171118062000".

20171118062000 -  1511039095000 = 18660078967000  !!

"18660078967000" more than real timestamp!! How can I fix it to grab correct time?