Re: [Xmltv-devel] tv_grab_uk_rt Performance

[Karl D. <de...@sp...>]

> I have spoken briefly to Robb about this and he has pointed at that I'm
> probably not handling the DST issues, and he was correct I've left this
> out initially (especially given the fact that DST only really becomes an
> issue for that 1 nasty hour a year when the time jumps backwards,
> forwards is easy to deal with due to no ambiguities). But this is
> a solvable problem.
>
> I've just started looking into this using some data I managed to grab
> from archive.org <http://archive.org> covering the two change dates (a
> few years back mind). And interestingly the library in use by xmltv gets
> the times wrong anyway! When the time goes forward I believe its
> correct, but when the time goes back it gets all muddled up.

We are using the DateTime modules on our NonameTV sites for time
handling. I try to fixup the guide around the DST switch but the
upstream data is ambiguous more often then not.

I usually tell the module "here comes Europe/Berlin local time" then do
math in UTC and convert back to local time with explicit offset for
output.
I've considered porting the whole of Xmltv over but currently lack the
time for such a big project.

> I'm going to try and spend some time making my _uk_rt mod DST aware, for
> the time being I'm focusing on mods directly in that code, rather than
> creating a replacement time processing lib that can be used by the other
> tv_grab routines. But that shouldn't be too tricky.

May I suggest to look at DateTime? Its working well for advanced stuff
like creating sets of time spans to cut and merge time sharing channels.
(see 
https://github.com/dekarl/nonametv/blob/master/lib/NonameTV/Importer/Combiner.pm#L439 
)

> My intention will be to provide a patch once I actually have something
> that works properly and includes all time checks etc... I'm happy to
> also provide my own python implementation, but to be honest I'd
> personally rather use the xmltv scripts (with mods) since these are well
> used/tested etc... However I may do some more work on my python scripts
> as it could form a useful testing ground (as I better understand the
> code) and a useful comparison.
>
> I'm not using the on-air guide since I only seem to be getting the
> now/next info, plus I believe EIT is only 7 days anyway? I'd rather have
> the full 2weeks if possible.

We have up to 4 weeks of DVB-EIT on satellite/cable in Germany. I don't
know how for the Freesat/Freeview MHEG guide goes into the future.

Regards,
Karl

PS: EIT is explicit about the time ;)