Parsing DateTime in C#: retarget net10.0 and fix the misused format constant - #2157
Open
vladimir-pecanac-main wants to merge 1 commit into
Open
Conversation
…file-scoped namespaces Retargets both projects net7.0 -> net10.0 and lifts the test packages: Microsoft.NET.Test.Sdk 17.3.2 -> 18.9.0, xunit 2.4.2 -> 2.9.3, xunit.runner.visualstudio 2.4.5 -> 4.0.0, coverlet.collector 3.1.2 -> 10.0.1. Fixes a real defect in the sample. DATEFORMAT_DDMYYYY_HHMMSS held a date string, "15/1/2023 10:12:12", and was passed as ParseExact's format argument. It did not throw: every digit in it is a literal character and "/" and ":" happen to match fr-FR's separators, so the pattern matched the input, extracted no date or time component, and ParseExact filled the empty result from the current date. The program printed today at midnight and changed every day, while the source comment claimed 15/01/2023 10:12:12 AM. The tests never saw it because ParseExactTest.cs uses the correct "dd/M/yyyy hh:mm:ss". The constant now holds that format string. Fixes a second drift against the article. The Parse(String) demonstration is the only one that parses with the current culture, and the article passes it a US-shaped string, "1/15/2023 02:21:37". The sample passed it the day-first string used by the fr-FR overloads, so the first demonstration threw a FormatException on a US machine and the whole Parse region was skipped. The two strings are now two constants, matching the article snippet by snippet. Output comments are reset from an actual run and now say which culture they assume, since Console.WriteLine formats a DateTime with CurrentCulture whatever culture parsed it. Console.ReadKey() is dropped so the sample can run non-interactively. Idiom lift: file-scoped namespaces in all five files, and Program.cs becomes top-level statements. The long method names are deliberately unchanged; they are the article's H3 titles made executable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sample for https://code-maze.com/csharp-convert-string-to-datetime/ (
dotnet-datetime/ParsingDateTimeInCSharp).Retarget
Both projects go
net7.0->net10.0. Test packages lifted to current:Microsoft.NET.Test.Sdk17.3.2 -> 18.9.0,xunit2.4.2 -> 2.9.3,xunit.runner.visualstudio2.4.5 -> 4.0.0,coverlet.collector3.1.2 -> 10.0.1. Versions queried from NuGet at the time of the change.A real defect in the sample
Program.csheldDATEFORMAT_DDMYYYY_HHMMSS = "15/1/2023 10:12:12"(a date string in a constant named FORMAT) and passed it asParseExact's format argument.It did not throw. Every digit in that "format" is a literal character, and
/and:happen to matchfr-FR's date and time separators, so the pattern matched the input, extracted no date or time component at all, andParseExactfilled the empty result from the current date. The program printed today at midnight and its output changed every day, while the source comment claimed15/01/2023 10:12:12 AM. The tests stayed green becauseParseExactTest.csuses the correct"dd/M/yyyy hh:mm:ss". The constant now holds that format string, and the run prints1/15/2023 10:12:12 AM.A second drift against the article
Parse(String)is the only demonstration that parses with the current culture, and the article passes it a US-shaped string,"1/15/2023 02:21:37". The sample passed it the day-first string that thefr-FRoverloads use, so on a US machine the first demonstration threw aFormatExceptionand thecatchswallowed the wholeParseregion: four further overloads never ran. The two strings are now two constants, matching the article snippet by snippet.Output comments are reset from an actual run and now state the culture they assume, because
Console.WriteLineformats aDateTimewithCurrentCultureregardless of which culture parsed it.Console.ReadKey()is dropped so the sample runs non-interactively.Idiom
File-scoped namespaces in all five files;
Program.csbecomes top-level statements. The very long method names are deliberately left alone: they are the article's H3 titles made executable.Verification
SDK 10.0.302.
dotnet build -c Release: 0 warnings, 0 errors.dotnet test -c Release: Passed 20, Failed 0.dotnet runcompletes end to end and every output comment matches what it printed.