#62774 Fix JWT Bearer unit tests failing if local timezone is UTC+N #62775
Conversation
…TC+N Tests were failing if local timezone is to the east of UTC, due to DateTime.MaxValue is locale-specific. Add explicit DateTimeKind UTC and immediate conversion to UTC when parsing, since this time is unrepresentable in local timezone
|
Thanks for your PR, @@navferty. Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes JWT Bearer unit tests that were failing when run in timezones east of UTC (UTC+N). The issue occurred because DateTime.MaxValue is locale-specific, causing test failures in certain timezone configurations.
Key changes:
- Explicitly set
DateTimeKind.Utcwhen creating JWT tokens withDateTime.MaxValueexpiration - Simplified DateTime parsing to directly convert to UTC using
DateTimeStyles.AdjustToUniversal
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/Security/Authentication/test/JwtBearerTests_Handler.cs | Updated JWT token creation and DateTime parsing to use explicit UTC handling |
| src/Security/Authentication/test/JwtBearerTests.cs | Applied identical fixes for JWT token creation and DateTime parsing consistency |
| @@ -944,8 +944,7 @@ public async Task ExpirationAndIssuedWhenMinOrMaxValue() | |||
| var expiresElement = dom.RootElement.GetProperty("expires"); | |||
| Assert.Equal(JsonValueKind.String, expiresElement.ValueKind); | |||
|
|
|||
| var elementValue = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture); | |||
| var elementValueUtc = elementValue.ToUniversalTime(); | |||
| var elementValueUtc = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); | |||
There was a problem hiding this comment.
Consider using DateTime.ParseExact or DateTimeOffset.Parse for more robust parsing of JWT timestamps, as JWT standards typically use ISO 8601 format. This would be more explicit about the expected format and reduce ambiguity.
| var elementValueUtc = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); | |
| var elementValueUtc = DateTime.ParseExact(expiresElement.GetString(), "yyyy-MM-ddTHH:mm:ss.fffffffK", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); |
Copilot uses AI. Check for mistakes.
| @@ -1000,8 +1000,7 @@ public async Task ExpirationAndIssuedWhenMinOrMaxValue() | |||
| var expiresElement = dom.RootElement.GetProperty("expires"); | |||
| Assert.Equal(JsonValueKind.String, expiresElement.ValueKind); | |||
|
|
|||
| var elementValue = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture); | |||
| var elementValueUtc = elementValue.ToUniversalTime(); | |||
| var elementValueUtc = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); | |||
There was a problem hiding this comment.
Consider using DateTime.ParseExact or DateTimeOffset.Parse for more robust parsing of JWT timestamps, as JWT standards typically use ISO 8601 format. This would be more explicit about the expected format and reduce ambiguity.
| var elementValueUtc = DateTime.Parse(expiresElement.GetString(), CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); | |
| var elementValueUtc = DateTime.ParseExact(expiresElement.GetString(), "o", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal); |
Copilot uses AI. Check for mistakes.
Tests were failing if local timezone is to the east of UTC, due to
DateTime.MaxValueis locale-specific. Add explicitDateTimeKindUTC and immediate conversion to UTC when parsing, since this time is unrepresentable in local timezoneFixes #62774