Introduction

A JavaScript Date value and a C# DateTime are not the same wire format. The reliable way to move a date from browser code to .NET is to serialize it into a neutral representation, usually an ISO 8601 string or a Unix timestamp, and then parse it on the server.

The most important decision is whether you want to preserve a time zone offset. If you do, DateTimeOffset is usually the safer .NET type than plain DateTime.

Use ISO 8601 as the Default Format

JavaScript already knows how to serialize a date into a standard format that .NET understands well:

1const now = new Date();
2const payload = {
3  createdAt: now.toISOString()
4};
5
6console.log(payload.createdAt);

A sample output looks like 2026-03-07T18:30:00.000Z. The trailing Z means UTC.

On the C# side, parse that string with DateTimeOffset.Parse or DateTimeOffset.TryParse:

1using System;
2using System.Globalization;
3
4var isoValue = "2026-03-07T18:30:00.000Z";
5var timestamp = DateTimeOffset.Parse(
6    isoValue,
7    CultureInfo.InvariantCulture,
8    DateTimeStyles.RoundtripKind
9);
10
11Console.WriteLine(timestamp);
12Console.WriteLine(timestamp.UtcDateTime);

This round-trip is dependable because both environments agree on the format. It also avoids culture-specific parsing issues such as 03/07/2026 meaning different things in different locales.

Sending Dates from a Browser to an ASP.NET API

In a real application, you usually send JSON rather than passing raw strings around by hand.

1const order = {
2  id: 42,
3  submittedAt: new Date().toISOString()
4};
5
6await fetch("/api/orders", {
7  method: "POST",
8  headers: {
9    "Content-Type": "application/json"
10  },
11  body: JSON.stringify(order)
12});

Then receive it in C# with a model type that preserves the offset information:

1public sealed class OrderRequest
2{
3    public int Id { get; set; }
4    public DateTimeOffset SubmittedAt { get; set; }
5}

If your API framework is configured normally, the JSON serializer will parse the ISO 8601 value automatically. That is usually cleaner than parsing strings manually in controller code.

When to Use DateTime Instead of DateTimeOffset

DateTime still works when you only care about a clock value and are disciplined about storing everything in UTC. For example:

1using System;
2using System.Globalization;
3
4var isoValue = "2026-03-07T18:30:00.000Z";
5var value = DateTime.Parse(
6    isoValue,
7    CultureInfo.InvariantCulture,
8    DateTimeStyles.AdjustToUniversal | DateTimeStyles.AssumeUniversal
9);
10
11Console.WriteLine(value.Kind);
12Console.WriteLine(value);

This produces a UTC DateTime. The problem is that DateTime can also represent Local and Unspecified values, so teams often lose track of what a value means. DateTimeOffset makes intent more obvious when data crosses process or network boundaries.

Using Unix Timestamps

Sometimes you do not want strings in your payload. In that case, send milliseconds since the Unix epoch.

const sentAtMs = Date.now();
console.log(sentAtMs);

Parse that in C# like this:

1using System;
2
3long sentAtMs = 1772917800000;
4DateTimeOffset timestamp = DateTimeOffset.FromUnixTimeMilliseconds(sentAtMs);
5
6Console.WriteLine(timestamp);

Unix timestamps are compact and language-neutral, but they are less readable in logs and harder to inspect manually than ISO strings.

Preserve Time Zone Intent

A common source of bugs is taking a local browser date and assuming the server will interpret it the same way. Consider this JavaScript code:

const localDate = new Date("2026-03-07T09:00:00");
console.log(localDate.toString());
console.log(localDate.toISOString());

The first string is shown in the browser's local zone. The second is converted to UTC. If the original meaning was "9 AM in the user's local zone," you should decide whether the server should store the instant in UTC, the original local time, or both.

For scheduling and user-facing calendars, that distinction matters a lot. For audit logs, storing UTC is usually enough.

Common Pitfalls

• Sending locale-formatted strings such as 03/07/2026 6:30 PM and expecting .NET to parse them consistently.
• Using DateTime everywhere without checking whether the value is Utc, Local, or Unspecified.
• Creating a JavaScript date from a local string and forgetting that toISOString() converts it to UTC.
• Storing Unix seconds on one side and reading them as Unix milliseconds on the other.
• Parsing dates manually in controller code when the JSON serializer could bind them directly to DateTimeOffset.

Summary

• Convert JavaScript dates to a neutral wire format before sending them to C#.
• Prefer ISO 8601 with toISOString() for readability and compatibility.
• Use DateTimeOffset in .NET when you want to preserve offset-aware values.
• Use Unix timestamps only when a numeric format is preferable for your API.
• Make time zone intent explicit, especially for scheduling and user-facing features.