Timezone and Date-Handling Correctness: A Proposed Axis for the Dates AI App Builders Emit (August 2026)

Quick answer (August 2026). Timezone and date-handling correctness measures whether the code an AI app builder emits stores, computes, and displays dates in a way that stays correct for users in other time zones and across daylight-saving transitions. It is one of the quietest failure classes in generated apps: the demo looks perfect on the builder's own machine, then a reminder fires an hour early in March, or a "due today" turns into "due yesterday" for a user five time zones away. This is a proposed BuilderProof axis, not a scored leaderboard. Like every BuilderProof axis it is designed to cover all five commercial builders we track (Bolt, v0, Lovable, Replit, Base44), be reproducible from published rules, and stay open to public revision. Below is the six-signal rubric we propose to score it with.

Why the date bug is the one that ships silently

Most generated-app defects announce themselves. A broken build fails to compile. A missing empty state renders a blank box. A date bug does neither. On the machine that generated the code, the server, the browser, and the author usually share one time zone, so a bare new Date(), naive storage, and default formatting all quietly agree. The app looks finished.

The defect only surfaces when the code meets a user in a different zone, a database that runs in UTC, or a clock that just crossed a daylight-saving boundary. By then the app is in production, and the symptom (an appointment off by an hour, a "yesterday" that should read "today") looks like a data-entry mistake rather than a systematic flaw.

That gap between "correct on the author's clock" and "correct for everyone" is exactly the kind of reproducible, cross-tool property BuilderProof exists to measure. It is the temporal cousin of the green-typecheck illusion we described in the type-safety posture axis: a passing surface that hides an unmeasured risk.

What this axis scores, and what it deliberately excludes

The axis scores the temporal correctness of the code a builder emits on a fixed prompt, read from the exported source and one scripted run of the app. It is not a judgment of any builder's design, speed, or model quality.

In scope:

• How timestamps are stored in the generated schema and write paths.
• How stored instants are converted for display.
• How the emitted code performs date arithmetic and parses date input.
• How dates cross the client-to-server boundary.

Out of scope (owned by other axes, or simply not this one):

• The visual layout of date pickers, which is a responsive-layout concern.
• Whether the empty or error state around a date renders at all, which is state-handling completeness.
• Translating month names beyond correct locale wiring, which borders internationalization output.

We draw the border explicitly so the axis stays reproducible and does not silently absorb neighboring concerns.

The proposed rubric: six signals, 100 points

Each signal is measured from the untouched export against a fixed prompt that asks the builder for a small scheduling app: create an event with a date and time, list events, and show a live "starts in" countdown. Points are additive; the rubric is documentation-derived and open for comment.

Total: 100 points. The weighting front-loads the decisions that everything else depends on.

Why storage carries the most weight

UTC-canonical storage earns the largest share because it is the decision every later signal inherits. If the instant is written without a zone, no amount of careful formatting downstream can recover the truth; the ambiguity is already baked into the row. The reliable primitives are a timestamptz column or an explicit UTC ISO-8601 string. The anti-pattern is a naive local timestamp that silently means "whatever zone the server happened to run in the day the code was generated."

Rendering: the runtime default is the trap

When you format a date without an explicit timeZone, MDN documents that Intl.DateTimeFormat uses "the runtime's time zone, the same time zone used by Date.prototype.toString()" (MDN, Intl.DateTimeFormat, 2026). On the builder's own machine that default is invisible and looks correct; for a user in another zone it is simply wrong. Full marks require the emitted code to pass an explicit timeZone (an IANA name such as America/New_York, or the viewer's resolved zone), not to lean on the default.

Arithmetic and parsing: where naive code breaks

Adding a day by adding 86,400,000 milliseconds is correct right up until a daylight-saving transition makes a civil day 23 or 25 hours long, at which point the reminder fires an hour off. Parsing is worse. MDN warns that date formats other than ISO 8601 are "implementation-defined and may not work across all browsers," documents that a string like "01-02-03" is read differently by different engines, and notes that this unreliability "is one of the motivations for the Temporal API" (MDN, Date.parse, 2026). Full marks require calendar-aware arithmetic and strict ISO-8601 parsing, never new Date("...") on arbitrary input.

The boundary: do not lose the zone in transit

A correct instant can still be corrupted the moment it crosses from server to client or into a JSON payload. RFC 3339, the internet profile of ISO 8601, requires a numeric offset (or Z for UTC) on every timestamp precisely so an instant survives serialization without ambiguity (IETF RFC 3339). Full marks require the emitted API to transmit offset-bearing timestamps end to end, so the client never has to guess which zone a bare string belonged to.

How we will measure this reproducibly

Every signal is read statically or from a single scripted run, per our benchmark methodology: grep the generated schema for zone-bearing column types, inspect the render path for an explicit timeZone argument, check the arithmetic for a library or Temporal call, parse one API response to confirm an offset is present. No human judgment of "looks right" enters the score. The same prompt and the same checks produce the same number on a re-run, which is the property that lets a result be cited and contested rather than trusted on faith.

The green-clock illusion

The reason this axis matters for buyers is that it is nearly invisible during evaluation. A prospective user builds a demo, sees a correct date, and moves on. The clock is green. The rubric is designed to defeat that illusion the same way a type checker defeats "it ran once": by measuring the structural decisions (where the zone lives, how the instant is stored, how it is transmitted) that determine correctness for the next thousand users, not just for the one who happened to share the author's clock.

What we are not claiming yet

This is an axis proposal. We are not publishing scores for any builder today, and nothing here ranks Bolt, v0, Lovable, Replit, or Base44 against one another. The rubric, the weights, and the fixed prompt are open for public comment before any scored run. If a signal turns out to be unmeasurable in practice, or a weight is wrong, we would rather fix it now than bake it into a leaderboard. As with every BuilderProof axis, the scores, once published, will be reproducible from these published rules and open to revision.

BuilderProof Editorial Team. "Timezone and Date-Handling Correctness: A Proposed Axis for the Dates AI App Builders Emit (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/timezone-date-handling-correctness-axis-proposal-august-2026.

@misc{builderproof-timezone-date-handling-correctness-axis-proposal-august-2026,
  title  = {{Timezone and Date-Handling Correctness: A Proposed Axis for the Dates AI App Builders Emit (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/timezone-date-handling-correctness-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}