Biome lint rule gap for regional time zone conversion logic
0 reputation · 22 Jun 2023, 14:21 UTC
0 reputation · 22 Jun 2023, 14:21 UTC
Biome's linter and formatter cover syntax and style, but the toolchain ships no native date-time utility. Projects that handle regional time zones therefore depend on the JavaScript Date object and the Intl API, whose behavior is sensitive to the host environment's locale and time zone settings.
The documented rule set flags deprecated Date methods, but timezone-aware string parsing and offset arithmetic appear to remain outside its scope. That leaves an unresolved design boundary: should Biome grow temporal-specific lint rules, or stay agnostic and delegate date correctness to libraries such as Luxon, Day.js, or the Temporal proposal?
Does Biome intend to add rules that detect unsafe regional time zone conversions, for example parsing date strings that implicitly assume the machine's local zone? Or is temporal correctness expected to stay outside the linter entirely, enforced only through external libraries and review conventions?
32275 reputation · 23 Jun 2023, 01:12 UTC
There is no confirmed public commitment that Biome will add lint rules that detect unsafe regional time zone conversions. The likely explanation is architectural: Biome is a static analyzer and formatter with no date-time runtime, so it cannot evaluate behavior that depends on the host machine's locale or zone. Temporal correctness is therefore expected to stay largely outside the linter's core scope, delegated to libraries and tests. Treat this as "not planned" rather than "never," and confirm against your installed version's rule list and release notes, since rule sets shift between minor releases.
Biome's rules are largely a curated subset of ESLint-style checks targeting syntax, style, and obvious API misuse. Judging whether a conversion is "unsafe" requires knowing the runtime zone, the input format, and the semantics of whichever date library is in use (Luxon, Day.js, or Temporal). A linter can only approximate this by banning API shapes, not by evaluating correctness. A clean lint run is never evidence of time-zone-safe code.
Date.parse("10/14/2026"), new Date() with non-ISO strings, or Intl.DateTimeFormat calls that omit an explicit timeZone option.TZ=UTC and a non-UTC zone in CI. This catches host-dependent parsing that no linter can see.Create a fixture and lint it to see what your version actually catches:
const a = new Date("10/14/2026");
const b = Date.parse("2026-10-14 20:35");
const c = new Date().toLocaleString();
const z = new Intl.DateTimeFormat().resolvedOptions().timeZone;If no diagnostics fire, that confirms the boundary: Biome stays agnostic, and zone safety is your test suite's job. The Temporal proposal may eventually give linters zone-aware types to reason about, but adoption is uneven, so don't plan around it.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.