Reply to thread

Message

<blockquote data-quote="Tony Wall" data-source="post: 1074589" data-attributes="member: 125233">UTC is fine for ignorant storage of data, when the original time offset is safe to discard and is not useful to anyone. If we don't care about what the original web response was then that's okay. But any update to the whole Media Portal code generally would make sense to switch to DateTimeOffset and review code to make sure no calculation loopholes (i.e. offset changes) were overlooked (TimeZoneInfo used for all calculations).But I don't see any point trying to avoid the use of the DateTimeOffset and TimeZoneInfo classes when they make things easier and for many good reasons are best to be utilized by default. So at least the source code should be using these classes to help with conversion, even if the time zone is never output to any file or API call.On the point of files, actually it would make sense to write the offsets and time zones used in calculations into the debug log file. That would help diagnose problems and enable users to verify that their foreign schedules were being imported correctly. This could be especially useful to help diagnose likely issues with misconfiguration of template grabber files (forgetting to change the time zone) or web sites which try to project schedules in an unexpected time zone, e.g. based on the .NET web client/browser language/IP range (seen too many of those, living abroad a long time myself).</blockquote>

[QUOTE="Tony Wall, post: 1074589, member: 125233"] UTC is fine for ignorant storage of data, when the original time offset is safe to discard and is not useful to anyone. If we don't care about what the original web response was then that's okay. But any update to the whole Media Portal code generally would make sense to switch to DateTimeOffset and review code to make sure no calculation loopholes (i.e. offset changes) were overlooked (TimeZoneInfo used for all calculations). But I don't see any point trying to avoid the use of the DateTimeOffset and TimeZoneInfo classes when they make things easier and for many good reasons are best to be utilized by default. So at least the source code should be using these classes to help with conversion, even if the time zone is never output to any file or API call. On the point of files, actually it would make sense to write the offsets and time zones used in calculations into the debug log file. That would help diagnose problems and enable users to verify that their foreign schedules were being imported correctly. This could be especially useful to help diagnose likely issues with misconfiguration of template grabber files (forgetting to change the time zone) or web sites which try to project schedules in an unexpected time zone, e.g. based on the .NET web client/browser language/IP range (seen too many of those, living abroad a long time myself). [/QUOTE]

Verification