Reply to thread

Message: <blockquote data-quote="Tony Wall" data-source="post: 1074645" data-attributes="member: 125233">Quite the opposite; UTC is not a time zone but a standard baseline which does NOT take ANY time zone into account, just used as a common reference. It's not only the baseline but also without any daylight saving time applied. It is often confused with GMT, which although similar for part of the year is not the same because GMT has British Summer Time applied. So for the first part GMT is UTC+00:00 then during BST it's UTC+01:00 then back to UTC+00:00 for the rest. If matters could not be worse, there are several other names for each time zone with each offset, e.g. Western European Time = GMT Winter, Western European Summer Time = GMT Summer.So when one says UTC they are actually saying "baseline AND no time zone AND no offset adjustment/daylight saving". The DateTime structure also has no offset, just a "local" or "UTC" flag (the "kind" property). As you know already, if you have DateTime data from more than one source you need to baseline them all to UTC before doing any conversion, but it's no magic wand... The part you didn't seem to grasp is that you must really use TimeZoneInfo to do calculations adding or removing dates in the same zone, or changing to any other zone, else you will corrupt data across offset changes twice a year.Now if that wasn't enough good reason to check out the current (not even new now) classes, because DateTimeOffset stores the offset (not a flag) you can skip the whole UTC conversion part and go directly between any time zone. That's why it's simply better. No data is lost, no need for UTC conversion, no problems if you need to convert the data in the future and understand what the user's perspective was, e.g. was it a Monday morning or Sunday night in Dubai when the problem occurred in a error report logged in the UK.Go read Wikipedia if you want to kill a few hours. Better spend 15 minutes reading the MSDN link I sent you and very simple examples which underline the issue and how easy (actually almost the same) it is to use DateTimeOffset compared to the OLD DateTime structure.If you really want to continue with just DateTime be careful with your UTC conversion; make sure you construct the DateTime with the Kind parameter specified every time, i.e. set it manually when parsing an exact format which doesn't specify an offset. Default is "unspecified" which usually means local system time (not UTC) but behaviour cannot be guaranteed because of other developers making similar mistakes.Just trying to help. I've been a professional .NET developer since the first beta (14 years now) and gained loads of experience with XML standards and serialization, data analysis and reports for global users, even written my own full featured scheduler classes (no simple feat when done properly). Anyway good luck with whatever you do with whatever classes! If nobody else manages it I might delve in myself and submit a fix later, or even a new plug-in (I have a better design I've used for a another product which would fit the EPG web site scraping pattern well).</blockquote>

Verification