[AzDev] Fix DateTime.Parse culture-sensitivity in Merge-DevPR#29343
[AzDev] Fix DateTime.Parse culture-sensitivity in Merge-DevPR#29343VeryEarly merged 1 commit intoAzure:mainfrom
Conversation
Use InvariantCulture when parsing createdAt dates from GitHub API to avoid FormatException on non-US locales where the default culture does not recognize MM/dd/yyyy date format. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status. |
There was a problem hiding this comment.
Pull request overview
This PR updates the AzDev PowerShell tooling to make Merge-DevPullRequest locale-independent when parsing PR createdAt timestamps returned from GitHub CLI.
Changes:
- Use
CultureInfo.InvariantCulturewhen parsingcreatedAtvalues at both call sites. - Keep the existing human-readable
CreatedAtoutput format for table display and returned objects.
| 'Title' = $_.title | ||
| 'CreatedBy' = $_.author.login | ||
| 'CreatedAt' = [DateTime]::Parse($_.createdAt).ToString('M/d/yyyy h:mm:ss tt') | ||
| 'CreatedAt' = [DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt') |
There was a problem hiding this comment.
ToString('M/d/yyyy h:mm:ss tt') is still culture-sensitive: in .NET custom format strings, / and : are replaced by the current culture’s date/time separators, and tt is culture-specific. On non-US locales this can produce output that diverges from the README’s expected 6/10/2024 2:15:30 PM style. To make the displayed/returned CreatedAt consistent across locales, pass CultureInfo.InvariantCulture to ToString(...) (or escape the separators if you intend literal / and :).
| 'CreatedAt' = [DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt') | |
| 'CreatedAt' = [DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt', [System.Globalization.CultureInfo]::InvariantCulture) |
| 'Title' = $_.title | ||
| 'CreatedBy' = $_.author.login | ||
| 'CreatedAt' = ([DateTime]::Parse($_.createdAt).ToString('M/d/yyyy h:mm:ss tt')) | ||
| 'CreatedAt' = ([DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt')) |
There was a problem hiding this comment.
Same issue as above: ToString('M/d/yyyy h:mm:ss tt') uses the current culture’s separators and AM/PM designators. If the cmdlet output is meant to be stable across locales (as implied by the README example), pass CultureInfo.InvariantCulture to ToString(...) so CreatedAt formatting doesn’t change per user locale.
| 'CreatedAt' = ([DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt')) | |
| 'CreatedAt' = ([DateTime]::Parse($_.createdAt, [System.Globalization.CultureInfo]::InvariantCulture).ToString('M/d/yyyy h:mm:ss tt', [System.Globalization.CultureInfo]::InvariantCulture)) |
isra-fel
changed the title
Description
[DateTime]::Parse()inMerge-DevPullRequestuses the current system culture by default. On non-US locales (e.g., where the default date format is DD/MM/YYYY), parsing a US-formatted date string like03/30/2026 21:57:01throws aFormatException.Fix
Pass
[System.Globalization.CultureInfo]::InvariantCultureas the second argument to[DateTime]::Parse()at both call sites (lines 139 and 206 inGitHub.psm1), ensuring consistent parsing regardless of the user's locale.Testing
Verified the fix resolves the
MethodInvocationExceptionwhen runningMerge-DevPR -AllArchivePR -Approveon a non-US locale system.