Incorrect Calculation - Doesn't Factor DST

[cpyfferoen]

You can't blanket use the Base Offset - it doesn't account for Daylight savings time.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 99e8b768-5ba6-c746-94c3-68f449a8bc68
• Version Independent ID: 5524a495-da5a-d554-41a5-858e57dc0688
• Content: How to: Resolve ambiguous times
• Content Source: docs/standard/datetime/resolve-ambiguous-times.md
• Product: dotnet
• Technology: dotnet-standard
• GitHub Login: @adegeo
• Microsoft Alias: adegeo

[adegeo]

Hello.

The article points out that

This topic shows how to resolve an ambiguous time by assuming that it represents the time zone's standard time.

Further it states:

Ordinarily, an ambiguous time is handled by calling the GetAmbiguousTimeOffsets method to retrieve an array of TimeSpan objects that contain the ambiguous time's possible UTC offsets. However, this example makes the arbitrary assumption that an ambiguous time should always be mapped to the time zone's standard time. The BaseUtcOffset property returns the offset between UTC and a time zone's standard time.

Is there a specific suggestion you have to change the article? I believe the code is accurate according the article intent.

[cpyfferoen]

Copy+paste+test revealed in my case that the time was incorrect (due to DST pretty sure) - so I thought it might be a glaring issue. I acknowledge the "fine print" does state these things. The only request would be

1. Alternate/more complete code example - as specified by the fine print OR...
2. Code comment - pointing out potential pit falls of this very simple example (DST for example)

[adegeo]

OK, I'll add it to the backlog. If you would like to contribute, you can submit a fix by editing the original article. Click on the Content Source link at the bottom of your original comment. To learn how to edit, see the Editing files in a repository article from GitHub.

Thanks again!