Fix DateTime parsing fails on non-US locale runners

[Copilot]

• Understand the issue: DateTime parsing fails when machines have different locale settings
• Identify affected files: WorkflowInitialize.ps1 (serialization) and WorkflowPostProcess.ps1 (deserialization)
• Fix WorkflowInitialize.ps1: Use ISO 8601 format (ToString("o")) for locale-agnostic serialization
• Fix WorkflowPostProcess.ps1: Convert datetime to UTC before calculating duration
• Extract datetime parsing logic into reusable ConvertToUtcDateTime function
• Test now reuses the actual function from WorkflowPostProcess.ps1 via dot-sourcing
• Add comprehensive test that validates with multiple locales (en-US, en-AU, de-DE, ja-JP)
• Run existing tests to ensure no regressions (all tests pass)
• Update RELEASENOTES.md in unreleased section
• Resolve merge conflicts with main branch (multiple times)

Summary

This PR fixes a bug where DateTime parsing fails on non-US locale runners (e.g., Australian locale) in WorkflowPostProcess.ps1.

Root Cause: The workflowStartTime was being serialized using the current culture's date format, but when deserialized on a machine with a different locale, the format didn't match, causing parsing failures.

Solution:

1. Serialize datetime in ISO 8601 format (ToString("o")) which is locale-independent
2. Parse datetime using ConvertToUtcDateTime function that ensures UTC conversion with InvariantCulture
3. Test validates the fix works across multiple locales and uses the actual function from the source file

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug]: DateTime parsing fails on non-US locale runners in WorkflowPostProcess.ps1</issue_title>
<issue_description>### AL-Go version

8.0

Describe the issue

The WorkflowPostProcess.ps1 script reports an error when running on self-hosted GitHub runners with non-US locale settings (e.g., Australian locale).

Error:

Exception calling "Parse" with "1" argument(s): "String '11/27/2025 05:17:03' was not recognized as a valid DateTime."

Location:
WorkflowPostProcess.ps1 line 71:

powershell$workflowTiming = [DateTime]::UtcNow.Subtract([DateTime]::Parse($telemetryScope.workflowStartTime)).TotalSeconds

Root Cause:
[DateTime]::Parse() uses the current culture settings. On Australian locale runners (dd/MM/yyyy format), it fails to parse US-format dates (MM/dd/yyyy) like 11/27/2025.

If timestamps are always in US format: Could consider using culture-invariant parsing, for example the below runs correctly when given a US date format on an australian locale machine

$workflowTiming = [DateTime]::Parse($telemetryScope.workflowStartTime, [System.Globalization.CultureInfo]::InvariantCulture)

Expected behavior

US date formats to work correctly when using non-US locale self hosted runners

Steps to reproduce

This Line from WorkflowPostProcess.ps1 line 71: but modified to run in powershell directly for testing.

PS C:\Windows\system32> $workflowTiming = [DateTime]::UtcNow.Subtract([DateTime]::Parse('11/27/2025 05:17:03')).TotalSeconds
Exception calling "Parse" with "1" argument(s): "String was not recognized as a valid DateTime."
At line:1 char:1
+ $workflowTiming = [DateTime]::UtcNow.Subtract([DateTime]::Parse('11/2 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : FormatException

If I change to use InvariantCulture

PS C:\Windows\system32> $workflowTiming = [DateTime]::UtcNow.Subtract([DateTime]::Parse('11/27/2025 05:17:03', [System.Globalization.CultureInfo]::InvariantCulture)).TotalSeconds
$workflowTiming 
81019.7661082

Additional context (logs, screenshots, etc.)

I believe the source of the issue is Line 71 of this file https://github.com/microsoft/AL-Go/blob/main/Actions/WorkflowPostProcess/WorkflowPostProcess.ps1

when $telemetryScope.workflowStartTime contains a US date format and the script is running on an Australian Locale self hosted runner it errors.

Internal work item: AB#614767</issue_description>

<agent_instructions>The issue is that that start datetime is serialized on a machine with different locale than the machine the start datetime is deserialized.

Please serialize the datetime in a way that is locale-agnostic.</agent_instructions>

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

• Fixes [Bug]: DateTime parsing fails on non-US locale runners in WorkflowPostProcess.ps1 #2045

---

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

[mazhelez]

@copilot don't forget the release notes 😉

[Copilot]

@copilot don't forget the release notes 😉

Added release notes entry in commit 3e1c750.

[mazhelez]

⚠️ Release Notes Update Reminder

Thank you for updating the release notes!

Please ensure that your changes are placed above the new version section (currently ## v8.1) in the RELEASENOTES.md file.

This helps maintain a clear changelog structure where new changes are grouped under the latest unreleased version.

[mazhelez]

⚠️ Release Notes Update Reminder

Thank you for updating the release notes!

Please ensure that your changes are placed above the new version section (currently ## v8.1) in the RELEASENOTES.md file.

This helps maintain a clear changelog structure where new changes are grouped under the latest unreleased version.

@copilot please fix the release notes.

[Copilot]

⚠️ Release Notes Update Reminder

Thank you for updating the release notes!

...

Fixed in commit 5702191. Moved the Issue 2045 entry to an unreleased section above the v8.1 version header.

[Copilot]

Pull request overview

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

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• www.nuget.org
  • Triggering command: /usr/bin/pwsh pwsh -c Invoke-Pester Tests/WorkflowPostProcess.Test.ps1 -PassThru (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.