Is it possible that the incorrect result is actually on your machine and not Azure, and is because you are initialising ScheduledDateUtc
as local time and not UTC?
Consider these two lines of code:
new DateTime(2015, 6, 1, 1, 1, 1).AddHours(5).ToUniversalTime().Dump();
new DateTime(2015, 6, 1, 1, 1, 1, DateTimeKind.Utc).AddHours(5).ToUniversalTime().Dump();
Here, we are in summer time which is UTC+1. The output of the above is:
01/06/2015 05:01:01
01/06/2015 06:01:01
They're 1 hour out as I 'forgot' to specify that the input is UTC in the constructor in the first line of code.
If you don't have access to the constructor because ScheduledDateUtc
is initialised by an ORM, you can use SpecifyKind
:
ScheduledDateUtc = DateTime.SpecifyKind(ScheduledDateUtc, DateTimeKind.Utc)
Its unfortunate that you're storing an offset not a timezone as you may have issues with daylight savings time. If you were storing a Windows timezone name, you could use TimeZoneInfo.ConvertTimeFromUtc
(no need to specify Kind
here as this assumes UTC) as per this example from MSDN:
TimeZoneInfo cstZone = TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time");
ScheduledDateLocal = TimeZoneInfo.ConvertTimeFromUtc(ScheduledDateUtc, cstZone);
You could instead instantiate a "custom" timezone using your offset and still use the above function.
I faced a similar issue where I had to schedule events based on a user's local time. I ended up storing the day of the week, hour, minute, and Olson timezone string, and used Noda-Time to convert to a DateTimeOffset and from there to server time.