An Angular invoice's due date shows one day early for some users; how do DatePipe's input parsing and time-zone argument explain it, and how do you fix it?

## The symptom An invoice shows a due date of **Feb 28** for some customers and **Mar 1** for others, although the backend stores one value. The template is ordinary: ```html Due {{ invoice.dueDate | date: 'mediumDate' }} ``` The cause is almost always the combination of **how `DatePipe` parses its input** and **which time zone it formats in**. ## Step 1: how `DatePipe` turns the value into a `Date` `DatePipe` accepts a `Date`, a number of milliseconds, or a string. For strings it distinguishes two cases: - a **date-only** ISO string such as `'2026-03-01'` is built as **local midnight** of that calendar date, deliberately avoiding the browser's habit of parsing date-only strings as UTC; - a **date-time** ISO string such as `'2026-03-01T00:00:00Z'` is an exact instant; the trailing `Z` means UTC midnight. If the API sends the due date as UTC midnight, the instant is correct, but it is still Feb 28 evening in the Americas. ## Step 2: which time zone it formats in The zone is chosen in this order: 1. the pipe's **second argument**, as in `date: 'mediumDate' : 'UTC'`; 2. the `timezone` field of the **`DATE_PIPE_DEFAULT_OPTIONS`** token, if provided; 3. otherwise the **end user's local system time zone**. With no argument and no token, each user sees the instant converted to their own zone, which moves UTC midnight to the previous day west of Greenwich. ## Step 3: fix it at the right layer | Situation | Fix | |---|---| | The value is a calendar date with no time meaning (due date, birth date) | Send a date-only string such as `'2026-03-01'`, so the pipe builds local midnight of that date | | The value is an instant, but invoices should read in one fixed zone | Pass the zone: `date: 'mediumDate' : 'UTC'`, or provide `DATE_PIPE_DEFAULT_OPTIONS` once | | The value is an instant and users should see their own local time | Leave the default, and label the time zone on screen | Providing a default for the whole application: ```ts providers: [{ provide: DATE_PIPE_DEFAULT_OPTIONS, useValue: { timezone: 'UTC' } }] ``` The older `DATE_PIPE_DEFAULT_TIMEZONE` token still exists but is deprecated in favour of `DATE_PIPE_DEFAULT_OPTIONS`. ## The trap inside the fix: what the zone argument accepts The time-zone argument is documented as an **offset** such as `'+0430'`, and `'UTC'` also works. It is not a full IANA-name API: Angular converts the string by asking `Date.parse` for an offset, and if that yields nothing usable it **silently falls back** to the date's own local offset. So a value like `'Europe/Berlin'` produces no error and no conversion. A fixed offset such as `'+0100'` also ignores daylight saving time. When you need real named-zone rules, format with the platform's `Intl` API in the component instead. ## A second classic: `YYYY` versus `yyyy` In `DatePipe` patterns, `y` is the **calendar year** and `Y` is the **ISO week-numbering year**, which differs from the calendar year for a few days around January 1. A pattern like `'dd/MM/YYYY'` would print the wrong year for, say, December 30. Current Angular guards this in development builds: a pattern containing `Y` without a week field `w` throws error `NG02300` ("Suspicious use of week-based year") wrapped as an invalid pipe argument, while the bare pattern `'YYYY'` only logs it. The check does not run in production builds, so the fix is to use `yyyy` and let the development error do its job. ## How to diagnose quickly 1. Log the raw value the template receives: is it date-only or a date-time with `Z` or an offset? 2. Check whether a zone argument or `DATE_PIPE_DEFAULT_OPTIONS` is in play, and whether its value is an offset `DatePipe` actually understands. 3. Reproduce by switching the operating system's time zone, or by testing the formatting with an explicit zone argument. 4. Scan date patterns for uppercase `Y`.