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="mnmr" data-source="post: 1074670" data-attributes="member: 86308"><p>Overall, I'm with Tony on this one, but do have a few remarks:</p><p></p><p>Working with a DateTime without knowing the associated time zone is much like reading a text file without knowing the encoding (you could get garbage or you could get the correct data, but you wouldn't know which one it was). Therefore, if you are parsing the date from a string, this either needs to include time zone information or you have to obtain the information elsewhere (e.g. configuration option for a particular EPG provider).</p><p></p><p>If you store the result of the parse operation in a DateTime, you need to know which time zone it is in. If you store the result in a DateTimeOffset, the time zone information will be preserved. I personally prefer to unify everything to UTC, because then you only need to consider time zone conversions when the DateTime "leaves your subsystem", such as when it is stored in a database or passed along to some other component not under your control.</p></blockquote><p></p>
[QUOTE="mnmr, post: 1074670, member: 86308"] Overall, I'm with Tony on this one, but do have a few remarks: Working with a DateTime without knowing the associated time zone is much like reading a text file without knowing the encoding (you could get garbage or you could get the correct data, but you wouldn't know which one it was). Therefore, if you are parsing the date from a string, this either needs to include time zone information or you have to obtain the information elsewhere (e.g. configuration option for a particular EPG provider). If you store the result of the parse operation in a DateTime, you need to know which time zone it is in. If you store the result in a DateTimeOffset, the time zone information will be preserved. I personally prefer to unify everything to UTC, because then you only need to consider time zone conversions when the DateTime "leaves your subsystem", such as when it is stored in a database or passed along to some other component not under your control. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Electronic Program Guide
WebEPG
WebEpg development
Contact us
RSS
Top
Bottom