Reply to thread

Message

<blockquote data-quote="doskabouter" data-source="post: 1074458" data-attributes="member: 98267">Don't know if it's ok to bump this thread (cant exactly call it hijacking <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> ), but I have a proposal for some webepg params.It's the #START and #END I'm struggling with.The times I receive are UTC formatted (f.e. 2014-04-07T23:00:00Z) and there's not yet a possibility to parse those.There's #STARTXMLTV which expects a long, and #START which boils down to HH:MM with minor variations.I did think of just adding a DateTime.TryParse to the #START code, but then there's now way to just parse UTC times other that specifying the exact format.If I don't specify the exact format, DateTime.TryParse would also correctly parse f.e. 23:45, with possibly unknown sideeffects (think timezones, offsets etc).So my proposal is to add #STARTGENERIC and #ENDGENERIC and use a simple dt=datetime.parse and do a worlddatetime.SetFromDateTime(dt), in general let the .NET runtime handle it.The names (#STARTGENERIC and #ENDGENERIC) are open for debate as I can't think of a proper name right now (see <a href="https://alpha.app.net/abraham/post/23590687" target="_blank">https://alpha.app.net/abraham/post/23590687</a> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> )Any thoughts?</blockquote>

[QUOTE="doskabouter, post: 1074458, member: 98267"] Don't know if it's ok to bump this thread (cant exactly call it hijacking :) ), but I have a proposal for some webepg params. It's the #START and #END I'm struggling with. The times I receive are UTC formatted (f.e. 2014-04-07T23:00:00Z) and there's not yet a possibility to parse those. There's #STARTXMLTV which expects a long, and #START which boils down to HH:MM with minor variations. I did think of just adding a DateTime.TryParse to the #START code, but then there's now way to just parse UTC times other that specifying the exact format. If I don't specify the exact format, DateTime.TryParse would also correctly parse f.e. 23:45, with possibly unknown sideeffects (think timezones, offsets etc). So my proposal is to add #STARTGENERIC and #ENDGENERIC and use a simple dt=datetime.parse and do a worlddatetime.SetFromDateTime(dt), in general let the .NET runtime handle it. The names (#STARTGENERIC and #ENDGENERIC) are open for debate as I can't think of a proper name right now (see [url]https://alpha.app.net/abraham/post/23590687[/url] :) ) Any thoughts? [/QUOTE]

Verification