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
• Add test case to verify datetime serialization/deserialization is locale-agnostic and UTC
• Run existing tests to ensure no regressions (6 tests passed)
• 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 and ensure it's converted to UTC using .ToUniversalTime() or DateTimeStyles.AdjustToUniversal

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

This PR fixes a locale-dependent DateTime parsing bug that caused workflow failures on non-US locale runners (e.g., Australian locale). The issue occurred when DateTime values serialized in one locale format couldn't be parsed in another locale.

Key changes:

• Serialize DateTime using ISO 8601 format (ToString("o")) for locale-agnostic representation
• Parse DateTime with InvariantCulture and AdjustToUniversal flags to ensure UTC timezone handling
• Add comprehensive test to validate locale-agnostic serialization/deserialization

Reviewed changes

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

File	Description
Actions/WorkflowInitialize/WorkflowInitialize.ps1	Changed DateTime serialization to use ISO 8601 format (ToString("o")) instead of default culture format
Actions/WorkflowPostProcess/WorkflowPostProcess.ps1	Updated DateTime parsing to handle both DateTime objects and strings, using InvariantCulture and UTC conversion
Tests/WorkflowPostProcess.Test.ps1	Added test case validating locale-agnostic DateTime serialization and UTC preservation
RELEASENOTES.md	Documented the fix for issue #2045 in the unreleased section

---

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

[mazhelez]

@copilot Can you please resolve the merge conflicts?

[Copilot]

@copilot Can you please resolve the merge conflicts?

Resolved merge conflicts in commit 5952fd6. The RELEASENOTES.md conflict has been merged, placing Issue 2045 in the unreleased section below the "AL-Go Telemetry updates" section and above v8.1.

[mazhelez]

@copilot Can you please resolve the merge conflicts?

Resolved merge conflicts in commit 5952fd6. The RELEASENOTES.md conflict has been merged, placing Issue 2045 in the unreleased section below the "AL-Go Telemetry updates" section and above v8.1.

@copilot can you look at it again? There are still merge conflicts.

[Copilot]

@copilot Can you please resolve the merge conflicts?

Resolved merge conflicts in commit 5952fd6. The RE...

Resolved the new merge conflicts in commit dbce971. The RELEASENOTES.md has been updated to include both Issue 2045 and the new "AL-Go repositories with large amounts of projects" issue in the unreleased section at the top.

[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.

[aholstrup1]

Wouldn't you need to set the locale in order for this test to test something meaningful? It seems like the issue came up because WorkflowPostProcess and WorkflowInitilize ran on different machines with different locales

[aholstrup1]

The whole test kind of just reimplements the logic from WorkflowPostprocess. Shouldn't we create a function in WorkflowPostprocess that we can call from here so we're testing the logic that actually runs in AL-Go workflows.