Menu
▾
▴
[Xmltv-devel] [ xmltv-Patches-2781993 ] Timezone handling in tv_grab_eu_epgdata
|
From: SourceForge.net <no...@so...> - 2009-05-29 16:18:22
|
Patches item #2781993, was opened at 2009-04-27 08:41 Message generated for change (Settings changed) made by mihaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=424137&aid=2781993&group_id=39046 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andreas Benneke (abeani) Assigned to: Nobody/Anonymous (nobody) Summary: Timezone handling in tv_grab_eu_epgdata Initial Comment: The attached patch improves the timezone handling for the epgdata by using the DateTime::Format::Strptime library (adds a dependency on "libdatetime-format-strptime-perl" on my Ubuntu). You may now specify the timezone using "local" (new default to use your system timezone - including daylight saving time switch if configured) "Europe/Berlin" (a specific time zone) or "+0200" (a specific offset from UTC) or even omit it to fall back to "local". Existing setups should continue to work as before since you may still specify the timezone as offset from UTC. ---------------------------------------------------------------------- Comment By: mhaas (mihaas) Date: 2009-05-29 16:17 Message: Committed. For future reference: new dependencies can be listed in Makefile.PL :) ---------------------------------------------------------------------- Comment By: mhaas (mihaas) Date: 2009-05-29 15:46 Message: Thanks for this great patch. I'm going to apply it in a second after verifying it's actually working ;) To answer your questions: AFAIK, packages for different countries will have different time zones.So, if you get a package for the UK, you will have GMT for example. However, we do know for which country we're downloading data - it's encoded in the file name and maybe also in the HTTP headers. It shouldn't be too hard to make such a table, but I'm way too busy with other things right now so I will just apply your patch as is. What happens when we download data which rolls over a timezone transition? Will we get different time zones in the same XML file or does it use the *current* time zone? ---------------------------------------------------------------------- Comment By: Ben Bucksch (benb) Date: 2009-04-27 23:06 Message: I think that's a great idea. I'll talk to them tomorrow. ---------------------------------------------------------------------- Comment By: Andreas Benneke (abeani) Date: 2009-04-27 22:03 Message: Another possibility came to my mind: What if the source data already contains country information we could us to determine the timezone from? I saw for example the filenames for Germany containing "de", I would suspect that the ones for France contain "fr", etc. If so, we could hardcode de -> Europe/Berlin fr -> Europe/Paris .. Or is there a better source for this information inside the source xml files? I do not have any documentation on that... What do you think? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-27 16:22 Message: I just double-checked: BBC World and CCN are translated into the german timezone and show up properly for me using my Germany epgdata.com subscription pin/link. I do not think, that there are multiple timezones in one single data file from epgdata.com - it does not make sense to have half of the times in "Europe/Berlin" and another half in "Europe/London" for example with no way to tell which is which. But: There are seem to be different channel sets for different countries: Take a look at the channel lists available at the different subscription links on http://wiki.xmltv.org/index.php/Europe - they seem to have different channels per country. They may also use different timezones for users subscribed from/for other countries...? Anybody out there having such a non-germany subscription? ---------------------------------------------------------------------- Comment By: Ben Bucksch (benb) Date: 2009-04-27 15:26 Message: The grabber has a list of supported channels in channel_ids. It's 120 or so, and you can see from the list that it's almost exclusively German channels, with only a few other language channels which are distributed in Germany. There's no BBC2 etc.. (I think the Grabber should be called de_epgadata, actually.) If you want to be sure that all channels are given in CET/CEST, you could check the schedule of some of the few English or Spanish channels, whether the schedule times are in German or station local timezone. I tried to call my administration contact at epgdata, but they're not in today, I can call again tomorrow, but I guess she doesn't know 100% either, as these are technical details. So, yes, I think it's indeed fine to assume German timezone. ---------------------------------------------------------------------- Comment By: Andreas Benneke (abeani) Date: 2009-04-27 14:52 Message: Ben, thank you for looking into it and your feedback. :-) Here is what I think/understood from the documentation and found in my test: We create a parser with the given timezone: DateTime::Format::Strptime->new( pattern => '%Y-%m-%d %H:%M:%S', time_zone => $tz ); As there is no timezone information in the pattern (or the input string), this parser simply assumes the given timezone for all parsed *input* strings. The given timestamp input string is just interpreted as a timestamp within the given timezone. The resulting $dt object is just the correct point in time. It however still carries the timezone information, but can easily be changed/converted to other timezones: my $start_stop_parser = DateTime::Format::Strptime->new( pattern => '%Y-%m-%d %H:%M:%S', time_zone => 'Europe/Berlin' ); my $dt = $start_stop_parser->parse_datetime( '2009-04-21 16:52:22' ); print $dt->strftime("%Y%m%d%H%M%S %z")."\n"; $dt->set_time_zone( 'Australia/South' ); print "Australia: ".$dt->strftime("%Y%m%d%H%M%S %z")."\n"; $dt->set_time_zone( 'America/New_York' ); print "New York: ".$dt->strftime("%Y%m%d%H%M%S %z")."\n"; $dt->set_time_zone( 'Europe/London' ); print "London: ".$dt->strftime("%Y%m%d%H%M%S %z")."\n"; $dt->set_time_zone( 'Europe/Berlin' ); print "Berlin: ".$dt->strftime("%Y%m%d%H%M%S %z")."\n"; Which is exactly what we want/need here... The output $dt->strftime("%Y%m%d%H%M%S %z") is only affected by the timezone used in the parser while choosing the value vor %z - all other values are calculated according to that and still specify that same point in time. Displaying that point in time should - as you already pointed out - left to the application using the data. As I can only see the data for Germany from epgdata.com I do not know anything about the timezones used in datasets for other countries. I therefore did not hardcode the timezone as you suggested, just because the data for a different country might be using a different timezone. If we can - as you seem to be sure of - safely assume the german timezone for ALL datasets for ALL countries, its perfectly safe to hardcode the timezone. But we should verify that with epgdata.com. If we cannot assume that, your are right and we should perhaps be more specific on the configuration question: "Enter your time zone or the time offset from UTC here." should read "Enter the time zone or the time offset from UTC of the data here." or something like that. ---------------------------------------------------------------------- Comment By: Robert Eden (rmeden) Date: 2009-04-27 14:31 Message: >In general, the problem to be solved here is that the data source does not >specify a timezone, but we need a globally unambiguous datetime including >timezone in the XMLTV file According to the DTD, if no timezone is specified, UTC should be assumed If that's not what the grabber intends, it's not ambiguous, it's wrong. ---------------------------------------------------------------------- Comment By: Ben Bucksch (benb) Date: 2009-04-27 13:37 Message: Andreas, thanks for your patch! Can you explain what exactly it does? You're using DateTime::Format::Strptime, but its documentation http://search.cpan.org/~RICKM/DateTime-Format-Strptime/ http://search.cpan.org/~rickm/DateTime-Format-Strptime-1.0900/lib/DateTime/Format/Strptime.pm http://code.google.com/p/datetime-format-strptime/ doesn't say exactly how parse_datetime() reacts to a string without timezone. Does assume the local timezone of the system, or does it assume the input timezone is in the timezone specified as *output* timezone in the constructor? In the first case, it would *convert* the local timezone to the timezone that you specifiy as output timezone. In general, the problem to be solved here is that the data source does not specify a timezone, but we need a globally unambiguous datetime including timezone in the XMLTV file. The data source implies the local German time: all programs are German or in the same timezone as Germany (Switzerland, France). Those programs which are not, e.g. BBC World News, CNN Europe, some Spanish stations, are probably returned with times matching the German timezone as well. So, it's not only fine, but correct to assume and hardcode the German timezone. The only reason why the original author didn't do that was that he didn't know how to express that, so that it would work with summer time: If you üut +0100 or CET, it's always winter time and off by one hour in summer. The author didn't know a Perl API to just say "Germany". Now you found such an API (thanks!) to express "Europe/Berlin", so we can just hardcode that. The XMLTV file will have "... 20:15:00 +0100" and "... 20:15:00 +0200" depending on summer/winter, and that's fine. There is no need to ask the that configuration question to the user. You could argue that a user in UK or Greece watching German programs might want to see the times in his local timezone. But I think that's a) the job of the program using the XMLTV data. All the programs I wrote, and MythTV, read the time simply as time spot (any time zone) using date functions and convert it to local time for display. b) a very uncommon case, not worth bothering the 99% of users in Germany with this confusing question. I think the current code will go wrong, because if you have somebody in UK, he'd enter his timezone (that's what you ask) and the XMLTV output will say e.g. "... 20:15:00 +0000", which is wrong. So, I think you should just drop the question "Enter your time zone or the time offset from UTC here" and hardcode "Europe/Berlin". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=424137&aid=2781993&group_id=39046 |