Cookie consent and privacy
Optional measurement and Google services run only after your consent. The consent panel (CMP) stores your choice; rejecting does not block the playgrounds.
Date/time

Day.js Date/Time Playground

Check Day.js formats, strict parsing, localized output, local vs UTC behavior and relative time before the date contract lands in code.

  • Input stays in the browser
  • Local and UTC comparison
  • Explicit plugin setup

Date formatting without guessing

Day.js is small, familiar and plugin driven, but production bugs often come from the small details: a missing customParseFormat plugin, a locale applied globally, a UTC timestamp rendered as local time or a format token that looks right but describes the wrong contract. This playground keeps those decisions visible.

The evaluator runs in the browser. The page does not send pasted dates, formats or snippets to a backend and does not store history.

Format and parse with Day.js

Choose a preset, adjust the input, parse format, output format, locale and mode, then compare local, UTC, localized and relative output.

Local

Start from an ISO timestamp and inspect a common dashboard format.

Input contract

Day.js output

Formatted
2026-05-26 09:30:00
ISO output
2026-05-26T09:30:00.000Z
Unix ms
1779787800000

Local output

2026-05-26 09:30:00

Uses the runtime/browser local timezone.

UTC output

2026-05-26 09:30:00

Parses and formats through dayjs.utc(...).

Localized output

Tuesday, May 26, 2026 9:30 AM

Uses the selected locale on the value instance.

Relative time

a few seconds ago

Computed from the deterministic referenceNow field.

Active plugins

  • customParseFormat
  • utc
  • localizedFormat
  • relativeTime
  • advancedFormat

Review notes

  • No custom parse format is active; Day.js uses its standard parser for this input.
  • Local mode uses the browser/runtime timezone. Compare with UTC before using the value in API payloads.

Reproducible snippet

import dayjs from 'dayjs';
import customParseFormat from 'dayjs/plugin/customParseFormat';
import utc from 'dayjs/plugin/utc';
import localizedFormat from 'dayjs/plugin/localizedFormat';
import relativeTime from 'dayjs/plugin/relativeTime';
import advancedFormat from 'dayjs/plugin/advancedFormat';

dayjs.extend(customParseFormat);
dayjs.extend(utc);
dayjs.extend(localizedFormat);
dayjs.extend(relativeTime);
dayjs.extend(advancedFormat);

const value = dayjs("2026-05-26T09:30:00Z").locale("en");
const output = value.format("YYYY-MM-DD HH:mm:ss");

What to verify before shipping date code

Format tokens

Tokens such as YYYY, MM, DD, HH, mm, ss, Z, dddd and LLL communicate a contract. Keep the intended output visible before copying it into API docs, UI labels or release scripts.

Local vs UTC

A timestamp with Z can look different in local mode than in UTC mode. Compare both before using a value in payloads, logs or release notes.

Locale and plugins

Day.js locales and plugins are explicit. This playground shows customParseFormat, utc, localizedFormat, relativeTime and advancedFormat so the snippet does not hide setup work.

Date strings often travel through formatted code and JSON payloads. Use the neighboring tools when the contract is broader than one Day.js expression.

Open Prettier Config PlaygroundOpen JSON Schema Validator

FAQ

Does this include full IANA timezone conversion?

No. The MVP is intentionally scoped to local vs UTC and locale output. A full timezone lab would be a separate product.

Why is referenceNow editable?

Relative time must be reproducible. A fixed reference date makes tests, docs and review comments deterministic.

Does the page change Day.js global locale?

No. The evaluator applies locale on the Day.js instance so tests and SSR requests do not inherit a hidden global locale.

Is this a replacement for repository tests?

No. Use it to inspect a date contract, then keep final parsing and formatting behavior covered in normal unit tests.

Day.js Date/Time Playground | Playground Forge

Format and parse dates before the contract lands in code

Test Day.js format tokens, custom parsing, locale output, local vs UTC behavior and relative time in a private browser playground.

01

Format and parse dates before the contract lands in code

Day.js Date/Time Playground focuses on the practical review moment before a date format reaches UI copy, API documentation, logs or release scripts. A developer can paste an ISO timestamp or a strict custom string, select local or UTC mode, choose English or Polish locale and compare the formatted result with localized and relative output. The goal is not to turn date handling into a vague demo. The page makes the real Day.js setup visible: customParseFormat for strict parsing, utc for release timestamps, localizedFormat for LLL/LLLL output, relativeTime for deterministic comparisons and advancedFormat for richer token coverage.

02

What the MVP checks

The MVP covers the common Day.js mistakes that create production noise: a parse format that does not match input, a timestamp with Z rendered as local time, locale that is expected but not loaded, and relative time that changes every time a reviewer refreshes the page. The evaluator keeps referenceNow editable so relative output is reproducible. Locale is applied on the Day.js instance rather than as a hidden global setting. The timezone scope is intentionally narrow: local versus UTC. Full IANA timezone conversion is not promised here because it deserves a separate product and bundle decision.

03

How to use the output in practice

Start with the preset closest to the contract you are reviewing. ISO local format is useful for dashboards and admin tables. Strict custom parse shows whether user-facing input such as DD/MM/YYYY HH:mm actually matches the parser. UTC release stamp is the safer review path for deployment notes, audit events and backend payloads. Localized format shows how LLLL changes under a selected locale, while relative time compares a target date against a fixed referenceNow field. After running the tool, inspect the formatted output, ISO output, Unix milliseconds and comparison rows. The snippet shows every plugin extension needed to reproduce the result in a repository. This page also explains what not to infer from the result. Local mode uses the runtime timezone. UTC mode uses dayjs.utc(...). Locale output depends on an imported locale and on applying .locale(locale) to the value instance. The playground deliberately avoids full timezone database claims. That boundary is important for trust: a public, private, browser-first tool should not pretend to be a complete scheduling system. If a team needs Europe/Warsaw versus America/New_York conversion, daylight-saving rules or a multi-timezone planner, that should become a separate scoped tool with its own tests. Use the comparison rows as a review checklist. If local and UTC are identical, confirm that this is intentional rather than an accident of the current environment. If localized output changes month names or weekday names, confirm that the target locale is imported in production code. If relative time is part of user-facing copy, keep the reference time deterministic in tests and avoid asserting against the current clock. If strict parsing fails, fix the input contract or parse format before adding fallback parsing. These checks are small, but they prevent the most expensive class of date bugs: a value that looks plausible in one timezone, language or runtime and silently means something else in another. The publisher content is part of the product rather than decoration. A visitor coming from search can understand format tokens such as YYYY, MM, DD, HH, mm, ss, Z, dddd and LLL, learn why customParseFormat must be loaded, and see why referenceNow matters for relative output. That makes the page useful before interaction and protects the site from becoming a thin widget. It also creates a natural bridge to neighboring Playground Forge tools: Prettier Config for snippets and documentation formatting, JSON Schema Validator for payload contracts, and TypeScript or ESLint tools when date strings travel through typed code.

04

When to move from playground to repository

Use the playground to agree on the date contract and copy a reproducible Day.js snippet. Then cover the final parse and format behavior with normal repository tests, especially when timezone assumptions, API payloads or localized user-visible labels are business-critical. Treat the copied snippet as an implementation checklist, not as a replacement for ownership in the target codebase. The repository should still decide where plugin extension happens, how locale bundles are loaded, whether UTC is the default for API boundaries and which tests freeze referenceNow. Product teams can use the same output in acceptance criteria: the expected visible label, the canonical ISO value, the Unix millisecond value and the warning boundary all fit into a short review note. That gives engineers, QA and writers a shared artifact without sending customer data to a server. For release work, keep one preset per contract family so regressions are easy to spot: admin table labels, audit event payloads, localized marketing copy and relative-time helper text should not silently share one vague date helper.