TimeZoneInfo.ConvertTime from PST to UTC to AEST - off by one hour

Question

I convert a string that represents a time in Pacific Time Zone that I am using to create a DateTime object:

var pacificDateTime = new DateTime(2016, 11, 16, 15, 0, 0) // 11/16/2016 3:00:00 PM

Using that, I create a DateTimeOffset because ultimately it becomes a bit easier to work with.

var pacificTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var dateTimeNoKind = new DateTime(pacificDateTime.Ticks, DateTimeKind.Unspecified)
var DateTimeOffsetValue = TimeZoneInfo.ConverTimeToUtc(dateTimeNoKind, pacificTimeZoneInfo) // 11/16/2016 11:00:00 PM

So far so good. The difference between UTC and Pacific is that UTC is ahead by 8 hours (the given time is within daylight savings).

Then I want to convert from UTC to AEST—but this is where the problem appears:

var australianEasternTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time");
TimeZoneInfo.ConvertTime(DateTimeOffsetValue, australianEasternTimeZoneInfo) // 11/17/2016 10:00:00 AM

AEST is ahead of UTC by 10 hours. I had expected the value to be 11/17/2016 09:00:00 AM but instead I am getting an extra hour added to my result.

As a test, when I convert to PST or GMT or EST from the UTC time, they appear to convert back correctly.

I feel like I am missing something obvious or overlooking something simple?

Homan

AEST is currently UTC+11, not UTC+10. We're in daylight savings. TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time").IsDaylightSavingTime(DateTime.UtcNow) – Finnish

@Finnish actually AEST is always UTC+10, it's just the Australia currently does not observe it but AEDT. – Hardiman

@Hardiman You're correct - that's a distinction I overlooked. However, "AUS Eastern Standard Time" maps internally to the same zone, with a DaylightName and StandardName – Finnish

@Finnish " However, "AUS Eastern Standard Time" maps internally to the same zone" --- that's what I could not find. Where does one check that? – Hardiman

@Hardiman What I meant to say is the library understands 'AUS Eastern StandardTime' to be a 'zone' with two names: Standard and Daylight. This zone is also responsible for the DST offset. If you were to write: TimeZoneInfo.FindSystemTimeZoneById("AUS Eastern Standard Time") - you retrieve a result with: BaseUtcOffset: 10:00:00, StandardName: AUS Eastern Standard Time, DaylightName: AUS Eastern Daylight Time, SupportsDaylightSavingTime: true. – Finnish

@Finnish It would be much easier if the Earth was flat... (/me sighs) – Hardiman

Best to trust your machine, looks like it has it right. On November 16th, Canberra is UTC+11 (DST in effect). San Francisco is UTC-8 (DST not in effect). A total of 19 hours offset, just what you got. – Siana

Microsoft stuffed up the naming. Hence the confusion. Calling it Standard Time is incorrect, as it combines both Standard AND Daylight. They made the same mistake with New York times. You will see people in USA with the same questions! Poor microsoft! – Oloughlin

Answer 1

From Wikipedia's Time in Australia article:

Australia has two eastern time zones. In the northeast, UTC+10 applies all year. In the southeast, UTC+10 applies during standard time, and UTC+11 applies during daylight time (aka summer time).

The northeast region (Queensland) uses the IANA time zone identifier "Australia/Brisbane", while the southeast region (New South Wales) uses "Australia/Sydney". These correspond to the Windows time zone identifiers: "E. Australia Standard Time" and "AUS Eastern Standard Time" respectively.

• If you are converting for Queensland, use "E. Australia Standard Time".

• If you are converting for New South Wales, use "AUS Eastern Standard Time".

As to the confusing nature of these identifiers, see the section about Windows time zones in the timezone tag wiki.

If you want to use the standard IANA identifiers instead, use Noda Time.

Omidyar