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: 1074884" data-attributes="member: 86308"><p>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.</p><p></p><p>As for naming, maybe STARTUTC / ENDUTC might work.</p></blockquote><p></p>
[QUOTE="mnmr, post: 1074884, member: 86308"] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Electronic Program Guide
WebEPG
WebEpg development
Contact us
RSS
Top
Bottom