0

I am getting some anomalies when using the C# built-ins to convert from ET to GMT. The program is parsing a file containing US Eastern Time zone date stamps for projected power loads. To store the info, the Eastern Time is converted to GMT. Code snippet is:

DateTime _date;
TimeZoneInfo et = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
TimeZoneInfo gmt = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");

...

DateTime.TryParse(table[_r, 0], out _date);
p.dtLocal = _date;
p.dtGMT = TimeZoneInfo.ConvertTime(p.dtLocal, et, gmt);

To start with, the function is adding 5 hours to Eastern to get GMT. The date today is Oct 22, 2017, so it should only be adding four hours. Secondly, on Oct 29th, at 1:00AM local, it changes to adding 4 hours. This change should take place after Nov 5, 2017 in the US, after which it should be adding 5 hours.

(before conversion)

dtGMT   {10/23/2017 12:00:00 AM} System.DateTime
dtLocal {10/23/2017 1:00:00 AM} System.DateTime

(after conversion)

dtGMT   {10/23/2017 6:00:00 AM} System.DateTime
dtLocal {10/23/2017 1:00:00 AM} System.DateTime

Am I using the functions incorrectly?

  • I'm not a C# dev (I'm here because I follow the [tag:timezone] tag), but I guess your question might be similar to [this one](https://stackoverflow.com/questions/2961848/how-to-use-timezoneinfo-to-get-local-time-during-daylight-savings-time) –  Oct 23 '17 at 13:17
  • 5
    It would be much easier to help you if you'd provide a [mcve] demonstrating the problem. My guess is that *really* you want UTC, instead of the UK time zone confusingly-represented by "GMT Standard Time". – Jon Skeet Oct 23 '17 at 13:20

1 Answers1

0

My bad. It is working as designed. Turns out that the ConvertTime uses the destination time zone to apply change rules, not the source zone.

The correct way to convert is ConvertTimeToUtc().

The DateTimeKind of the p.dtLocal was unspecified.

//p.dtGMT = TimeZoneInfo.ConvertTime(p.dtLocal, et, gmt);
p.dtGMT = TimeZoneInfo.ConvertTimeToUtc(p.dtLocal, et);
  • 1
    This still gives you a 4hr offset on the 30th Oct when you expected a 5hr offset. Have you determined the root of this discrepancy? – SpruceMoose Oct 23 '17 at 13:33
  • 3
    Not weird when you read my comment from 28 minutes ago - `TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time")` is not the same as `TimeZoneInfo.Utc`. – Jon Skeet Oct 23 '17 at 13:49
  • 3
    "Turns out that the ConvertTime uses the destination time zone to apply change rules, not the source zone." No, it uses both. It uses the source zone to work out which instant in time was represented to start with, and then the destination zone to work out what the local time for that instant is in the destination zone. – Jon Skeet Oct 23 '17 at 14:13