Convert a future local DateTime into UTC

Question

I'm facing an issue converting a EWS Appointment's start DateTime from the local time into UTC. From EWS, I get the Appointment's DateTime and TimeZone. I have been using .ToUniversalTime() to convert the DateTime to UTC.

However, when the current time and the Appointment's start time are on different sides of daylight savings time (for example, the start DateTime might be March 15, 2018), the .ToUniversalTime() conversion uses the current UTC offset, which results in a DateTime that is off by one hour.

I need some way of getting the UTC offset at a future date.

My best plan is to use .ToUniversalTime() to get an approximation of the correct UTC start DateTime. Most of the time, this will be the correct UTC conversion, and when it's not, it'll be close. Theoretically, I should be able to get a predicted UTC offset at this estimated UTC time, and reconvert the original start DateTime to UTC.

I'm aware this will fail if the start DateTime occurs within an hour after daylight savings time switches, but that's close enough for me. I would appreciate any suggestions or alternate methods, but what I'm really searching for is some way of getting the estimated UTC offset at some future date.

Answer 1

A few things:

• DateTime.ToUniversalTime() can only convert from the system's local time zone. It doesn't know anything about the time zone in your appointment.

• You are incorrect that it uses the current UTC offset. It uses the offset in effect at the time provided. Again, it only knows about the offset from the system's local time zone.

  • Note that if you are running on very old OS (Windows XP), it would only know about the current rule (for time zones that have changed their rules). But this is all handled correctly in modern Windows.

• Instead of .ToUniversalTime(), consider using the the TimeZoneInfo object, and its ConvertTimeToUtc method. Since you already have a time zone from EWS, this is likely the easiest route.

• The only "estimation" involved is that you are estimating the time zone rules won't change in the future. This may or may not come to be. Since we cannot see into the future, we cannot possibly know. Your code itself does not need to do any estimation - the functions provided by the framework are precise enough, given the data they have available.

• There is already a ton of information on this subject here on StackOverflow. Please search before asking. Thanks.