home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Electronic Program Guide
WebEPG
WebEpg development
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Tony Wall" data-source="post: 1074572" data-attributes="member: 125233"><p>The correct way to deal with this data is with DateTimeOffset for storage and TimeZoneInfo for calculation. Especially because this guide data very likely comes from different time zones (at least for satellite users) or will change across yearly offset changes.</p><p></p><p>Check this article out for a complete explanation. What I'm saying here IS the current recommended "default" by Microsoft:</p><p></p><p><a href="http://msdn.microsoft.com/en-us/library/bb384267(v=vs.110).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/bb384267(v=vs.110).aspx</a></p><p></p><p>Regarding naming of any new parameter, please not "generic", there is a proper name for this XML format, I think it's "ISO" but double-check MSDN and wikipedia or something first. I'm surprised the guys at XMLTV didn't use the standard format either (their format looks like the "sortable" format without offset).</p><p></p><p>It's also going to be important to honour the time zone settings in each grabber file, and calculate the stop time so that recordings crossing an offset change really record the whole program, not one hour less or more for example. It also depends on whether the source listings are start+duration or start+stop times, either way it's important to use TimeZoneInfo to calculate the true length/stop-time whatever MediaPortal requires (still haven't programmed that myself yet, but soon...).</p><p></p><p>As many programmers forget or choose to ignore the necessary complexities of things like globalization and time zones, I wouldn't be surprised if during development some bugs in the TV server scheduler itself were found.</p></blockquote><p></p>
[QUOTE="Tony Wall, post: 1074572, member: 125233"] The correct way to deal with this data is with DateTimeOffset for storage and TimeZoneInfo for calculation. Especially because this guide data very likely comes from different time zones (at least for satellite users) or will change across yearly offset changes. Check this article out for a complete explanation. What I'm saying here IS the current recommended "default" by Microsoft: [url]http://msdn.microsoft.com/en-us/library/bb384267(v=vs.110).aspx[/url] Regarding naming of any new parameter, please not "generic", there is a proper name for this XML format, I think it's "ISO" but double-check MSDN and wikipedia or something first. I'm surprised the guys at XMLTV didn't use the standard format either (their format looks like the "sortable" format without offset). It's also going to be important to honour the time zone settings in each grabber file, and calculate the stop time so that recordings crossing an offset change really record the whole program, not one hour less or more for example. It also depends on whether the source listings are start+duration or start+stop times, either way it's important to use TimeZoneInfo to calculate the true length/stop-time whatever MediaPortal requires (still haven't programmed that myself yet, but soon...). As many programmers forget or choose to ignore the necessary complexities of things like globalization and time zones, I wouldn't be surprised if during development some bugs in the TV server scheduler itself were found. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Electronic Program Guide
WebEPG
WebEpg development
Contact us
RSS
Top
Bottom