"Invalid Date" in "Date" column on order list in backoffice

[nickfrederiksen]

Which component is this issue related to?

Umbraco Commerce (Core)

Which Umbraco Commerce version are you using? (Please write the exact version, example: 10.1.0)

15.3.10

Bug summary

In the backoffice, when listing orders the Date column only shows "Invalid Date".

Specifics

The date seems to be correctly formatted from the API:

However every date is displayed like this:

When loading an order details page, the same issue seems to persist here as well:

Steps to reproduce

Finalize an order.
Navigate to Commerce -> Store -> Orders in the backoffice.
Look at the Date column.

Click on an order, look at the date below the order number.

Expected result / actual result

The actual date to be displayed.

Dependencies

No response

[mattbrailsford]

What culture is your server running on? Your dates look incorrect. They seem to be using . instead of : for the time element so where you have 2025-07-29T08.24.54Z (which fails to convert to a JS Date via new Date("2025-07-29T08.24.54Z")) I have 2025-07-21T10:20:56.217Z (which successfully converts to a JS date via new Date("2025-07-21T10:20:56.217Z"))

[mattbrailsford]

Do you have any custom JSON serialization settings configured anywhere? From what I can find online, this isn't the default format for any particular culture so some code somewhere must be explicitly serializing dates in that format. I'm wondering if you've registered any JSON serialization settings that might be conflicting.

[nickfrederiksen]

Just tried something. We have this piece of code:

builder.Services.Configure<RequestLocalizationOptions>(options =>
{
	string[] supportedCultures = ["da"];
	options.SetDefaultCulture(supportedCultures[0])
		.AddSupportedCultures(supportedCultures)
		.AddSupportedUICultures(supportedCultures);
});

Which has been in production, and worked flawlessly since february. But after the latest update to Commerce, (or maybe this is an Umbraco issue?), it started interferring with json serialization. Removing these lines seems to fix the problem.

[mattbrailsford]

Hmm, so it could be linked to this issue that was in the last update #728 in which we do now force all dates to be UTC format from the Commerce API endpoints, however I'm not sure why that would be the issue as it should be using this converter which is very explicit over it's format

public class DateTimeConverter : JsonConverter<DateTime>
{
    public override DateTime Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        => DateTime.Parse(reader.GetString() ?? string.Empty).ToUniversalTime();

    public override void Write(Utf8JsonWriter writer, DateTime value, JsonSerializerOptions options)
        => writer.WriteStringValue(value.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ"));
}

[mattbrailsford]

Hmm, let me try passing CultureInfo.InvariantCulture to the ToString call

[mattbrailsford]

I'm guessing this is the issue:

The key issue is that : is not a literal character in DateTime format strings - it's a time separator placeholder that gets replaced with the current culture's time separator.

So CultureInfo.InvariantCulture should resolve it. I've pushed a 15.3.11--preview.2 to the nightly feed if you want to try that and confirm it fixes the issue for you.

[nickfrederiksen]

It seems to have fixed the issues.

[mattbrailsford]

Excellent! Are you ok running on the nightly for the time being? We did a release yesterday and I prefer to keep at least a week between releases if it's not a showstopper issue.

[nickfrederiksen]

It's OK. Seems stable enough.

[mattbrailsford]

It's the only bug fix in that build at the moment so it shouldn't be any less stable than the current release build.