v0.2.1 — honest docs, real-world recipes, public conformance suite

Documentation and metadata only. The published code is byte-identical to 0.2.0 — no token, API or behaviour change. Upgrading is safe and optional.

Fixed

• package.json repository, bugs and homepage pointed at a repository name that no longer exists.

Documentation

• Removed the overstated claim that "nothing is lost". Nanoseconds, UTC offset and IANA zone id do survive a round trip; the calendar does not. The new "Calendars — current limitation" section shows a Hebrew-calendar round trip coming back as a different day, and the ISO-conversion workaround.
• New Recipes section: yyyyMMdd, LDAP generalized time, Luxon fromFormat migration, date-fns migration, zoned nanosecond timestamps — each backed by a test.
• New comparison against Temporal, Luxon, date-fns and temporal-fmt.

Added

• Public conformance suite — conformance/cases.json, 65 machine-readable cases covering DST gaps and overlaps, inputs that must be rejected, extreme years, offset and zone spellings, and 1–9 fractional-second digits. It is data, not code, so any Temporal token library can be run against it.

Which date format are you stuck with? #2

v0.2.0

[0.2.0] — 2026-07-25

Two additive token groups. No behaviour changes to existing patterns — every 0.1.1
pattern formats and parses byte-identically.

Added

• 12-hour clock tokens h / hh (hour 1–12) and a (AM/PM), valid on
  PlainTime, PlainDateTime and ZonedDateTime. 12:00 AM is midnight, 12:00 PM
  is noon; parsing accepts any case (pm, Pm, PM). This is fixed English text, not
  CLDR data, so the zero-dependency and no-locale guarantees are unchanged.
  • A pattern mixing H with h/a is rejected as contradictory
    (InvalidPatternError).
  • On parse, h requires a and a requires h; an hour outside 1–12 fails loudly.
• UTC offset variants X (±HH, widening to ±HHMM when minutes are non-zero),
  XX (±HHMM) and XXX (±HH:MM). All three render UTC as the literal Z and
  accept Z on parse, normalizing it to +00:00. Existing ZZ is untouched: always
  ±HH:MM, never Z.
  • Sub-minute historical offsets can't be represented in any X form and throw a
    FormatError pointing at ZZ.
• Test suite: dedicated reflect coverage and temporal-sql-style edge-case tests
  (pre-1970 and proleptic/BC years, years ≥ 10000, leap-day validity, DST fall-back
  fold, fractional-second and boundary-time precision), plus 12-hour and offset-variant
  coverage plumbed into the fast-check round-trip properties.
• CI: GitHub Actions workflow — a check matrix on Node 18/20/22/24/26 (26 exercises
  native Temporal) plus a separate attw tarball-gate job.

v0.1.1

[0.1.1] — 2026-07-21

Initial release.

Added

• format(value, pattern) — token formatting directly on any Temporal value
  (PlainDate, PlainTime, PlainDateTime, PlainYearMonth, PlainMonthDay,
  ZonedDateTime). No JavaScript Date in the code path.
• parse(input, pattern, targetTypeName, options?) — numeric token parsing that
  constructs a real Temporal value via native globalThis.Temporal or a
  caller-supplied { temporal } implementation.
• Unicode TR35-style numeric token set: yyyy yy y MM M dd d HH H mm m ss s S…
  plus ZZ (UTC offset) and VV (IANA zone id) for ZonedDateTime. Single-quoted
  literals ('T', '').
• Per-type token validity checks; documented two-digit-year (yy) pivot
  (00–68 → 2000s, 69–99 → 1900s); overflow: "reject" so out-of-range input fails
  loudly.
• getTemporalType, isTemporal, and the error types FormatError, ParseError,
  InvalidPatternError.
• Zero runtime dependencies. Dual CJS/ESM builds with .d.ts/.d.cts; subpath
  exports temporal-format-parse/format and temporal-format-parse/parse for tree-shaking.