NestJS 10 ValidationPipe Date Transformation Change: Impact on DTO Date Fields

Direct answer

No. NestJS 10 does not provide a built-in ValidationPipe flag to force Date properties to UTC, and it should not. The pipe is a transport validation boundary; timezone policy is an API-contract and domain decision. A JavaScript Date stores an instant and does not remember the original offset, so a pipe-level UTC flag cannot preserve the source offset for audit trails.

Likely explanation versus confirmed facts

Likely explanation: after upgrading to NestJS 10, implicit date coercion is no longer dependable. Without transform: true on the global ValidationPipe, an ISO-8601 string reaches the controller as a string. With transform: true, class-transformer can instantiate a Date, but it keeps the offset embedded in the input string unless you configure the conversion explicitly.

Confirmed facts:

• new Date('2026-10-16T12:00:00') is interpreted using the server's local timezone, not UTC.
• Date.prototype.toISOString() always serializes as UTC, while toString() depends on the runtime timezone.
• IsDate() validates a Date instance, while IsISO8601() validates a string.
• Exact ValidationPipe defaults and class-transformer Date handling vary by installed versions; verify against your lockfile.

Recommended pattern: uniform UTC with audit retention

1. Enable transform: true on the global ValidationPipe and add explicit @Type(() => Date) to every DTO date field. Prefer this over enableImplicitConversion, which can silently coerce unrelated fields.
2. Normalize incoming date-times to UTC at the boundary. If the client sends 2026-10-16T12:00:00+02:00, the stored domain value should be 2026-10-16T10:00:00.000Z.
3. Preserve the original offset outside the Date. Log the raw request body before ValidationPipe runs, or add an explicit audit-only field such as originalOffset if the contract requires it. Adding a field changes the API contract, so version the DTO or keep audit data in logs instead.
4. For zone-aware calculations, parse with Luxon or date-fns-tz, derive the UTC instant, and keep the zone or offset in a separate value. Do not expect a JS Date to remember the offset.

Example DTO

import { Type } from 'class-transformer';
import { IsISO8601 } from 'class-validator';

export class CreateEventDto {
  @Type(() => Date)
  @IsISO8601()
  startsAt: Date;

  @Type(() => Date)
  @IsISO8601()
  endsAt: Date;
}

Pipe registration

app.useGlobalPipes(
  new ValidationPipe({
    transform: true,
    whitelist: true,
    forbidNonWhitelisted: true,
  }),
);

Version-gating NestJS 9 to 10

Do not branch on the NestJS major version at runtime. Make transform: true and explicit date decorators the single code path for both versions, then run the same DTO contract tests in a CI matrix covering NestJS 9 and 10. Gate the merge on identical results. Use a feature flag only to switch between UTC normalization and offset preservation as policy, not as a compatibility shim.

Verification steps

1. Post { "startsAt": "2026-10-16T12:00:00+02:00" } through the global pipe with transform: true and assert the controller receives a Date whose toISOString() is 2026-10-16T10:00:00.000Z.
2. Repeat with transform: false and without @Type to confirm the value remains a string in your installed versions.
3. Log the raw request body before ValidationPipe and compare it with the normalized DTO to prove the original offset is retained for audit.

One missing diagnostic detail that could change this recommendation: do you need the original offset available inside the application layer, or is server-side request logging sufficient for audit? If application code requires it, add an explicit audit field; otherwise, raw body logging is the safer, contract-stable choice.