Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers #123805

Copilot · 2026-01-30T18:21:40Z

Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers

Summary:
This PR fixes a consistency issue where DateOnly.TryParse/TryParseExact and TimeOnly.TryParse/TryParseExact methods were returning false for invalid DateTimeStyles parameters instead of throwing an ArgumentException, which is inconsistent with other TryParse APIs in .NET.

Changes Made:

Moved DateTimeStyles validation to the public Parse/TryParse methods (upfront validation before calling internal methods)
Moved format validation (null/empty checks) to the public ParseExact/TryParseExact methods (upfront validation)
Simplified internal methods - they no longer need to check for argument validation errors
Modified all TryParse and TryParseExact overloads in both DateOnly and TimeOnly to throw exceptions for invalid DateTimeStyles values
Enhanced TryParseExactInternal methods to detect and immediately return Argument_BadFormatSpecifier errors from underlying DateTimeParse.TryParseExact
Updated existing tests to expect exceptions instead of false returns
Added comprehensive tests for all TryParseExact variants with invalid styles and format specifiers
All tests use AssertExtensions.Throws with the "style" parameter name for consistency
All 69,639 tests passing (0 failures, 0 errors)

Pattern Consistency:
The implementation now follows the same pattern as DateTime, DateTimeOffset, and numeric types by validating arguments upfront in the public methods before calling internal parsing logic. This:

Reduces code duplication
Avoids unnecessary work when arguments are invalid
Makes the code more maintainable
Aligns with framework conventions

Breaking Change:
Yes. This is a breaking change as code that previously received false will now throw an exception. However, this aligns with the behavior of other TryParse APIs and improves consistency. The scenarios affected are those that could never succeed (invalid argument combinations), so the impact should be minimal.

Examples:

// Before: returned false
DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", null, DateTimeStyles.AssumeUniversal, out var result);
// After: throws ArgumentException with ParamName = "style"

// Before: returned false  
DateOnly.TryParseExact("2064-07-01", new[] { "", "yyyy-MM-dd" }, null, DateTimeStyles.None, out var result);
// After: throws FormatException

Files Modified:

src/libraries/System.Private.CoreLib/src/System/DateOnly.cs - Implementation changes
src/libraries/System.Private.CoreLib/src/System/TimeOnly.cs - Implementation changes
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateOnlyTests.cs - Test updates
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeOnlyTests.cs - Test updates

Fixes #111969

Original prompt

This section details on the original issue you should resolve

<issue_title>DateOnly TryParseExact fails to parse basic ISO-8601 input</issue_title>
<issue_description>### Description

Ive had to hunt down a bug, where I swapped a DateTime.TryParseExact with a DateOnly.TryParseExact and had to find out, DateOnly refuses to work with DateTimeStyles.AssumeUniversal.

DateOnly.TryParseExact behaves inconsistently compared to DateTime and DateTimeOffset when parsing the same ISO-8601 formatted date string and DateTimeStyles.AssumeUniversal is supplied.

This is either a bug, or a highly misleading API, since (as far as I could find) nothing in the documentation indicates that DateTimeStyles.AssumeUniversal is invalid or unsupported for DateOnly.

Reproduction Steps

using System;
using System.Globalization;

Console.WriteLine("DateTime:");
Console.WriteLine(DateTime.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _));
Console.WriteLine(DateTime.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _));
		
Console.WriteLine("\nDateTimeOffset:");
Console.WriteLine(DateTimeOffset.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _));
Console.WriteLine(DateTimeOffset.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _));
		
Console.WriteLine("\nDateOnly:");
Console.WriteLine(DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _));
Console.WriteLine(DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _));

// Output:
// DateTime:
// True
// True

// DateTimeOffset:
// True
// True

// DateOnly:
// False
// True

Expected behavior

Return true, parsing the input correctly without failure.
Or alternatively, as others suggested, throw a clear exception.

Actual behavior

Return false, whereas similar (if not under the hood identical) APIs for DateTime and DateTimeOffset return true.

Regression?

No response

Known Workarounds

Use DateTimeStyles.None instead

Configuration

Target Framework: NET 10
SDK: 10.0.102
Arch.: x64

Other information

No response</issue_description>

<agent_instructions>We need to fix all DateOnly and TimeOnly TryParse and TryParseExact methods to throw exception when passing invalid DateTimeStyle parameter instead of just return false. Ensure adding a new tests cover the fix and if possible, file a new breading change issue in https://github.com/dotnet/docs/issues using the breaking change template.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@tarekgh This is not a bug. `DateOnly` and `TimeOnly` are intentionally designed to be independent of time zones. They represent abstract date and time values that are not associated with any region or time zone.

The official documentation clearly explains this behavior:

https://learn.microsoft.com/en-us/dotnet/standard/datetime/how-to-use-dateonly-timeonly#the-dateonly-structure

The DateTime structure may roll into the previous or next day when adjusted for a time zone. DateOnly cannot be offset by a time zone and always represents the exact date that was set.

If you have any suggestions to improve any docs, please feel free to submit issue or a PR in https://github.com/dotnet/dotnet-api-docs. Thanks for your report.

@tannergooding @tarekgh I believe the supposed bug here is that unlike other `TryParse` APIs, `DateOnly` doesn't throw for an invalid style and simply returns `false` making it inconsistent with the general rule that we should only have one mode of failure.

That is, there is no string that would make DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _) succeed and therefore DateTimeStyles.AssumeUniversal is "invalid" for DateOnly and should be throwing accordingly (as all of our other TryParse APIs behave with invalid styles)</comment_new>
<comment_new>@tarekgh
@tannergooding you are correct regarding that but honestly, I am not sure if this deserve to fix for the sake of consistency while it introduces a breaking change we can avoid. Let me know if you still think we should fix it and we can consider it. Thanks!</comment_new>
<comment_new>@tannergooding
We've got at least one customer report on it already and it is something that creates other potential problems for users, i.e. its a static bug and so any typical "get user input, try to ...

Fixes DateOnly TryParseExact fails to parse basic ISO-8601 input #123802

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

…imeStyles Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

…tency Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

src/libraries/System.Private.CoreLib/src/System/DateOnly.cs

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateOnlyTests.cs

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeOnlyTests.cs

tarekgh · 2026-01-30T22:08:57Z

@copilot please address all opened feedback

…thods Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

… for bad format specifiers Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot · 2026-01-30T22:46:23Z

        {
@copilot DateTimeParse.TryParseExact can return zero and set the dtResult.failure to ParseFailureKind.Argument_BadFormatSpecifier but the method TryParseExactInternal will return Pa...

Fixed in 492c226. Now checking dtResult.failure and preserving Argument_BadFormatSpecifier if returned by DateTimeParse.TryParseExact.

        {
@copilot my comment on DateOnly file will apply here too.
...

Fixed in 492c226. Applied the same fix for TimeOnly single format overload.

        {
@copilot My comment on DateOnly file apply here too.
...

Fixed in 492c226. Applied the same fix for TimeOnly multiple formats overload.

    }
@copilot This method should preserve ParseFailureKind.Argument_BadFormatSpecifier if it is returned in dtResult.failure
...

Fixed in 492c226. Now tracking and preserving Argument_BadFormatSpecifier across the loop iterations.

@copilot please address all opened feedback

All feedback addressed in commit 492c226. Summary of changes:

Fixed all TryParseExactInternal methods to preserve Argument_BadFormatSpecifier from DateTimeParse.TryParseExact
Added tests for invalid format specifiers (null/empty formats)
All 69,639 tests passing

src/libraries/System.Private.CoreLib/src/System/TimeOnly.cs

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

tarekgh · 2026-01-31T00:39:14Z

/asp run runtime

Copilot

Pull request overview

This PR fixes a consistency issue where DateOnly.TryParse/TryParseExact and TimeOnly.TryParse/TryParseExact methods were returning false for invalid DateTimeStyles parameters instead of throwing an ArgumentException, aligning their behavior with other TryParse APIs in .NET. Additionally, it ensures that invalid format specifiers (null/empty formats in arrays) properly throw FormatException instead of being masked as general format errors.

Changes:

Modified all TryParse and TryParseExact overloads in both DateOnly and TimeOnly to throw exceptions for invalid DateTimeStyles values
Enhanced TryParseExactInternal methods to detect and immediately return Argument_BadFormatSpecifier errors from underlying DateTimeParse.TryParseExact
Updated existing tests to expect exceptions instead of false returns, and added comprehensive new test cases for all variants

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/DateOnly.cs	Modified `TryParse` and all `TryParseExact` overloads to throw on invalid `DateTimeStyles`; enhanced `TryParseExactInternal` to detect bad format specifiers
src/libraries/System.Private.CoreLib/src/System/TimeOnly.cs	Modified `TryParse` and all `TryParseExact` overloads to throw on invalid `DateTimeStyles`; enhanced `TryParseExactInternal` to detect bad format specifiers
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateOnlyTests.cs	Updated existing tests to expect exceptions; added comprehensive tests for invalid styles and format specifiers
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeOnlyTests.cs	Updated existing tests to expect exceptions; added comprehensive tests for invalid styles and format specifiers

tarekgh · 2026-02-01T18:44:58Z

CC @stephentoub

src/libraries/System.Private.CoreLib/src/System/DateOnly.cs

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

tannergooding

LGTM. It'd probably be nice to have the style checking in a single centralized helper, like it is for the other types, but this is much more consistent now

github-actions · 2026-02-03T17:33:42Z

📋 Breaking Change Documentation Required

Create a breaking change issue with AI-generated content

Generated by Breaking Change Documentation Tool - 2026-02-03 17:33:42

@tarekgh

… format specifiers (dotnet#123805) ## Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers **Summary:** This PR fixes a consistency issue where `DateOnly.TryParse`/`TryParseExact` and `TimeOnly.TryParse`/`TryParseExact` methods were returning `false` for invalid `DateTimeStyles` parameters instead of throwing an `ArgumentException`, which is inconsistent with other `TryParse` APIs in .NET. **Changes Made:** - [x] Moved `DateTimeStyles` validation to the public Parse/TryParse methods (upfront validation before calling internal methods) - [x] Moved format validation (null/empty checks) to the public ParseExact/TryParseExact methods (upfront validation) - [x] Simplified internal methods - they no longer need to check for argument validation errors - [x] Modified all `TryParse` and `TryParseExact` overloads in both `DateOnly` and `TimeOnly` to throw exceptions for invalid `DateTimeStyles` values - [x] Enhanced `TryParseExactInternal` methods to detect and immediately return `Argument_BadFormatSpecifier` errors from underlying `DateTimeParse.TryParseExact` - [x] Updated existing tests to expect exceptions instead of `false` returns - [x] Added comprehensive tests for all `TryParseExact` variants with invalid styles and format specifiers - [x] All tests use `AssertExtensions.Throws` with the "style" parameter name for consistency - [x] All 69,639 tests passing (0 failures, 0 errors) **Pattern Consistency:** The implementation now follows the same pattern as `DateTime`, `DateTimeOffset`, and numeric types by validating arguments upfront in the public methods before calling internal parsing logic. This: - Reduces code duplication - Avoids unnecessary work when arguments are invalid - Makes the code more maintainable - Aligns with framework conventions **Breaking Change:** **Yes.** This is a breaking change as code that previously received `false` will now throw an exception. However, this aligns with the behavior of other `TryParse` APIs and improves consistency. The scenarios affected are those that could never succeed (invalid argument combinations), so the impact should be minimal. **Examples:** ```csharp // Before: returned false DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", null, DateTimeStyles.AssumeUniversal, out var result); // After: throws ArgumentException with ParamName = "style" // Before: returned false DateOnly.TryParseExact("2064-07-01", new[] { "", "yyyy-MM-dd" }, null, DateTimeStyles.None, out var result); // After: throws FormatException ``` **Files Modified:** - `src/libraries/System.Private.CoreLib/src/System/DateOnly.cs` - Implementation changes - `src/libraries/System.Private.CoreLib/src/System/TimeOnly.cs` - Implementation changes - `src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateOnlyTests.cs` - Test updates - `src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeOnlyTests.cs` - Test updates Fixes dotnet#111969  <details> <summary>Original prompt</summary> ---- *This section details on the original issue you should resolve* <issue_title>DateOnly TryParseExact fails to parse basic ISO-8601 input</issue_title> <issue_description>### Description Ive had to hunt down a bug, where I swapped a `DateTime.TryParseExact` with a `DateOnly.TryParseExact` and had to find out, `DateOnly` refuses to work with `DateTimeStyles.AssumeUniversal`. `DateOnly.TryParseExact` behaves inconsistently compared to `DateTime` and `DateTimeOffset` when parsing the same ISO-8601 formatted date string and `DateTimeStyles.AssumeUniversal` is supplied. This is either a bug, or a highly misleading API, since (as far as I could find) nothing in the documentation indicates that `DateTimeStyles.AssumeUniversal` is invalid or unsupported for `DateOnly`. ### Reproduction Steps ```C# using System; using System.Globalization; Console.WriteLine("DateTime:"); Console.WriteLine(DateTime.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _)); Console.WriteLine(DateTime.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _)); Console.WriteLine("\nDateTimeOffset:"); Console.WriteLine(DateTimeOffset.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _)); Console.WriteLine(DateTimeOffset.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _)); Console.WriteLine("\nDateOnly:"); Console.WriteLine(DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _)); Console.WriteLine(DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out _)); // Output: // DateTime: // True // True // DateTimeOffset: // True // True // DateOnly: // False // True ``` ### Expected behavior Return true, parsing the input correctly without failure. Or alternatively, as others suggested, throw a clear exception. ### Actual behavior Return false, whereas similar (if not under the hood identical) APIs for `DateTime` and `DateTimeOffset` return true. ### Regression? _No response_ ### Known Workarounds Use `DateTimeStyles.None` instead ### Configuration Target Framework: NET 10 SDK: 10.0.102 Arch.: x64 ### Other information _No response_</issue_description> <agent_instructions>We need to fix all DateOnly and TimeOnly TryParse and TryParseExact methods to throw exception when passing invalid DateTimeStyle parameter instead of just return false. Ensure adding a new tests cover the fix and if possible, file a new breading change issue in https://github.com/dotnet/docs/issues using the breaking change template.</agent_instructions> ## Comments on the Issue (you are @copilot in this section) <comments> <comment_new><author>@tarekgh</author><body> This is not a bug. `DateOnly` and `TimeOnly` are intentionally designed to be independent of time zones. They represent abstract date and time values that are not associated with any region or time zone. The official documentation clearly explains this behavior: [https://learn.microsoft.com/en-us/dotnet/standard/datetime/how-to-use-dateonly-timeonly#the-dateonly-structure](https://learn.microsoft.com/en-us/dotnet/standard/datetime/how-to-use-dateonly-timeonly#the-dateonly-structure) > The `DateTime` structure may roll into the previous or next day when adjusted for a time zone. `DateOnly` cannot be offset by a time zone and always represents the exact date that was set. If you have any suggestions to improve any docs, please feel free to submit issue or a PR in https://github.com/dotnet/dotnet-api-docs. Thanks for your report. </body></comment_new> <comment_new><author>@tannergooding</author><body> @tarekgh I believe the supposed bug here is that unlike other `TryParse` APIs, `DateOnly` doesn't throw for an invalid style and simply returns `false` making it inconsistent with the general rule that we should only have one mode of failure. That is, there is no string that would make `DateOnly.TryParseExact("2064-07-01", "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.AssumeUniversal, out _)` succeed and therefore `DateTimeStyles.AssumeUniversal` is "invalid" for `DateOnly` and *should* be throwing accordingly (as all of our other `TryParse` APIs behave with invalid styles)</body></comment_new> <comment_new><author>@tarekgh</author><body> @tannergooding you are correct regarding that but honestly, I am not sure if this deserve to fix for the sake of consistency while it introduces a breaking change we can avoid. Let me know if you still think we should fix it and we can consider it. Thanks!</body></comment_new> <comment_new><author>@tannergooding</author><body> We've got at least one customer report on it already and it is something that creates other potential problems for users, i.e. its a static bug and so any typical "get user input, try to ... </details>  - Fixes dotnet#123802  --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Initial plan

e00c070

Copilot AI assigned Copilot and tarekgh Jan 30, 2026

Copilot started work on behalf of tarekgh January 30, 2026 18:21 View session

tarekgh added this to the 11.0.0 milestone Jan 30, 2026

tarekgh added breaking-change Issue or PR that represents a breaking API or functional change over a previous release. needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet area-System.DateTime labels Jan 30, 2026

Copilot AI and others added 4 commits January 30, 2026 18:28

Fix DateOnly and TimeOnly TryParse methods to throw for invalid DateT…

ffcbf22

…imeStyles Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Add comprehensive tests for TryParseExact with invalid DateTimeStyles

9109304

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Use AssertExtensions.Throws with style parameter for test consistency

8bf2e12

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Fix DateOnly.TryParse tests to use AssertExtensions.Throws for consis…

67645f9

…tency Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix DateOnly TryParseExact inconsistent behavior with ISO-8601~~ Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles Jan 30, 2026

tarekgh reviewed Jan 30, 2026

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/DateOnly.cs Outdated Show resolved Hide resolved

Copilot finished work on behalf of tarekgh January 30, 2026 21:55

Copilot started work on behalf of tarekgh January 30, 2026 21:55 View session

tarekgh reviewed Jan 30, 2026

View reviewed changes

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateOnlyTests.cs Show resolved Hide resolved

tarekgh reviewed Jan 30, 2026

View reviewed changes

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeOnlyTests.cs Show resolved Hide resolved

Remove unnecessary Argument_BadFormatSpecifier check from TryParse me…

9b82b31

…thods Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot AI requested a review from tarekgh January 30, 2026 22:20

Copilot finished work on behalf of tarekgh January 30, 2026 22:20

Copilot started work on behalf of tarekgh January 30, 2026 22:20 View session

Preserve Argument_BadFormatSpecifier from DateTimeParse and add tests…

492c226

… for bad format specifiers Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot AI changed the title ~~Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles~~ Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers Jan 30, 2026

Copilot finished work on behalf of tarekgh January 30, 2026 22:47

This was referenced Jan 30, 2026

iOS.Device test WorkItemExecutions #122874

Open

XHarness package install failure on iOS due to devicectl NSPOSIXErrorDomain error 49 #123796

Open

Copilot started work on behalf of tarekgh January 30, 2026 23:12 View session

tarekgh reviewed Jan 30, 2026

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/TimeOnly.cs Outdated Show resolved Hide resolved

Copilot AI requested a review from tarekgh January 30, 2026 23:17

Copilot finished work on behalf of tarekgh January 30, 2026 23:17

Copilot started work on behalf of tarekgh January 30, 2026 23:18 View session

Return immediately when Argument_BadFormatSpecifier is encountered

57a5c63

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot finished work on behalf of tarekgh January 30, 2026 23:41

Copilot started work on behalf of tarekgh January 30, 2026 23:42 View session

Copilot finished work on behalf of tarekgh January 30, 2026 23:45

tarekgh marked this pull request as ready for review January 31, 2026 00:35

tarekgh requested review from Copilot and tannergooding January 31, 2026 00:35

Copilot started reviewing on behalf of tarekgh January 31, 2026 00:36 View session

dotnet deleted a comment from azure-pipelines bot Jan 31, 2026

Copilot AI reviewed Jan 31, 2026

View reviewed changes

build-analysis bot mentioned this pull request Jan 31, 2026

[Wasm] The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing #123572

Open

tannergooding reviewed Feb 2, 2026

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/DateOnly.cs Outdated Show resolved Hide resolved

Copilot started work on behalf of tarekgh February 2, 2026 16:38 View session

Validate styles and formats upfront in public methods for consistency

440212b

Co-authored-by: tarekgh <10833894+tarekgh@users.noreply.github.com>

Copilot finished work on behalf of tarekgh February 2, 2026 17:17

tannergooding approved these changes Feb 2, 2026

View reviewed changes

tarekgh merged commit 1555505 into main Feb 3, 2026
142 of 146 checks passed

tarekgh mentioned this pull request Feb 3, 2026

[System.Private.Xml] Possible incorrect behavior in character counting ( maxCharsCount >= charsCount ) #111969

Open

tarekgh mentioned this pull request Feb 3, 2026

[Breaking change]: Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers dotnet/docs#51438

Open

tarekgh removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Feb 3, 2026

tannergooding deleted the copilot/fix-dateonly-parse-issue branch February 3, 2026 18:16

dotnet-maestro bot mentioned this pull request Feb 5, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#4680

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers #123805

Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers #123805

Uh oh!

Copilot AI commented Jan 30, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tarekgh commented Jan 30, 2026

Uh oh!

Copilot AI commented Jan 30, 2026 •

edited

Loading

Uh oh!

Uh oh!

tarekgh commented Jan 31, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

tarekgh commented Feb 1, 2026

Uh oh!

Uh oh!

tannergooding left a comment

Uh oh!

Uh oh!

github-actions bot commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers #123805

Fix DateOnly/TimeOnly TryParse to throw on invalid DateTimeStyles and format specifiers #123805

Uh oh!

Conversation

Copilot AI commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!