WebEpg development (1 Viewer)

[mnmr]

I'll second that, although it might still make sense to store local times in the database (it'll save a lot of unnecessary conversions, as the clock is also in local time - easier for both tv-engine and ui). The important thing is to have a convention and sticking to it.

 

[mm1352000]

Yes, storing local times might save conversions in some cases... but I still vote for UTC. DVB broadcast EPG (probably most used EPG source) uses UTC, so the conversion savings might actually be bigger if we stored UTC. The other reason for storing UTC would be to avoid problems with daylight savings changes. Local times in the database is a real problem if you want reliable daylight savings handling.

 

[mnmr]

Good points with DST. My vote goes to UTC also.

 

[doskabouter]

Well, I've seem to start quite a discussion.

To react to Tony's quite thoroughly explanation:
I think I didn't make myself 100% clear.
Of course I'll use DateTimeOffset instead of DateTime if that's better, but my main question was about what to parse and validate.
Do I stick to UTC only for parsing, or anything that .NET will validate?

And for the record, one of the things I learned in my 20+ years of software development is knowing when to be cautious!

As for the contents of databases (in fact any persistant storage): +1 for UTC

 

[mnmr]

The parsing question is really rather simple: the feed provider will have some sort of documentation on the content of the feed, and you will most likely need to support a variety of formats.

If you parse a date string and it doesn't include TZ info, then you need to have that from somewhere else in order to produce correct UTC dates. So, the short answer is, it depends on what you're parsing

 

[doskabouter]

Then I think I'm going for a DateTimeOffset.Parse instead of ParseExact.
It will be the most flexible.
I'll see if I can put it (with backwards compatibility ofcourse) under the #START and #END tags

 

[doskabouter]

I see that #START and #END only capture hour an minute into the WorldDateTime class.
If I extend it to something like DateTimeOffset.Parse it could possibly (small chance in my opinion) break existing grabbers, and to prevent that I'll need 2 new tags after all.
Should I take the risk and extend #START and #END, or has anyone has a nice name for the new tags?

 

[mnmr]

I'm afraid I don't know anything about the code or what you're trying to achieve, and without context it's hard to give concrete advice. But it sounds like there are multiple consumers of the file format you are producing, so before introducing breaking changes you should consider whether these existing parsers based on the old format would produce a correct result? That is, if they interpret the data as a local time, but the time is actually in UTC, then it doesn't matter if you change the format - they would be broken anyway. However, if they do produce correct results and you cannot simply update them, then introducing a new field might be a better solution.

As for naming, maybe STARTUTC / ENDUTC might work.

 

[wjw]

Didn't dive into that (yet), mostly doing some small patches into the webepg parser.
Perhaps skip those in the parser, so the importer doesn't freak out on them?

Would be great if you could fit this into your other mods.

 

[Tony Wall]

Is there source missing or is this just one solution file which is out of date and where can I find the designer source?

(see attached image)

I want to add the feature to format the EPOCH_DATE in the URL request as hexadecimal. Something like EPOCH_DATE_HEX and without a "0x" in front so the user can choose when it is required (by typing it manually before when so). A better longer term solution would be taking something like a standard formatting mechanism similar to the .NET format strings, but for now extra variable or two will suffice.[DOUBLEPOST=1397995480][/DOUBLEPOST]Sheez, guys you need to sort out dependencies! Two golden rules (to start with):

1) No files outside solution root, they will not be automatically acquired, updated or checked-in.
2) Check-in/make available built copies of dependencies at a central location.
3) Add some scripts to make it easy to pull in updated dependencies to each local solution source tree.

Personally I prefer a "Dependencies" folder within each solution root and a sequence of build scripts which make them easy to update. See my blog article on this subject...
http://codechief.wordpress.com/2013/03/24/versioning-visual-studio-solutions-the-easy-way/

For now I will battle on and try to get some kind of quick fix into whatever I manage to build from WebEPG. But it's way more difficult than it should be and I wouldn't be surprised if many bugs come simply from outdated references.

Okay I guess the build script/dependency issue needs to be raised on a more central Media Portal development forum. Unless I missed some build system which is already doing this (but I doubt that considering the missing source code). So excuse me if I did not RTFM I've just got a major headache with EPG I've got to solve for me personally at least (even if the pull request is not accepted).

On a longer term if everything goes okay with this in the end I might contribute more to Media Portal development.