support desk · kb

#4471 review · two date paths, not one fix

owner chrigu desk-closed reviewed 2026-10-28 · 0 days ago

Scope and source of truth

This review uses the exported report records, tenant directory, desk notes, and the functions that build the desk’s tables. It is an export snapshot, not a claim about the current queue. The build date is not a later data-refresh date. Rebuild with a fresh export before using these counts as current.

Engineering update — 5 October 2026

The Challenge page now reports “#4471 · closed 05 oct”:

These are different resolutions. A retired form is not evidence that its hint was repaired. The outcomes are reported by the desk, not independently verified by our local rendering tests. The export counts below remain historical; this update adds no new report records.

Separate tickets

At export time, the parser read numeric dates month first. For day-first tenants, an intended day/month value can become a month/day value. This affects app and email reports, and booking-v2 form reports. Engineering now reports a locale-aware parser fix, not just a different label.

The other path was booking-v3’s form: its hint said MM/DD/YYYY while the form interpreted input in the tenant’s day-first order. A repair would need the hint and interpretation to agree. Engineering instead retired the form. The parser fix did not repair that hint.

The table uses tenant locale and booking-form version, not browser locale or intake tags. Locale order is obtained through Intl.DateTimeFormat, not a hard-coded country list. Duplicate export rows count once by report ID; different IDs remain distinct reports, including corrections or follow-ups. Counts describe reports, not affected people.

412 distinct reports merged into #4471, from through . The export contains 427 rows: 15 repeated rows are excluded.

Problem / candidate causeReportsTenantsReceivedTicket
Shared parser assumes month-first input (parser)379112026-04-01 → 2026-10-04GitHub issue
booking-v3 hint conflicts with day-first form interpretation (hint)3332026-04-17 → 2026-09-22GitHub issue

38 intake tags disagree with the tenant/form classification. Intake tags describe an initial browser-based guess; they are not a reliable count by cause.

Computed causeIntake tags in this group
parserparser: 356 · hint: 23
hintparser: 15 · hint: 18

Exceptions: classification is not a complete diagnosis

The desk flagged 5 report IDs as “one-day moves”. They remain included in the computed parser count above, not an additional population. The bodies below do not prove that all of them share one cause. In particular, R-41236 describes an invite arriving before a booking, not an explicit one-day shift. Timezone or date-boundary behavior is an investigation hypothesis, not an established fix.

ReportTenant / channelReporter evidence
R-41202kettle.books / emailInvite says Tuesday 12 May. Calendar says Monday 11 May. My client turned up on the Monday. We had coffee.
R-41209alder.physio / appEvery booking in June is one day off. Only June. Why only June.
R-41236nine.lanterns / appThe invite arrived before I made the booking. I would like to know how.
R-41344pale.harbour / emailClient in Lisbon got Tuesday. Client in Toronto got Monday. Same meeting. We held it twice.
R-41620lantern.row / emailTuesday 6 October showed as Monday. I moved it myself. I have stopped reporting these but my colleague says it helps you.

Other narratives below describe impact, workarounds, or a month displacement without enough input/output detail to establish a specific mechanism. They also stay in their existing computed group. Do not present every report in that group as a demonstrated month/day swap.

ReportReporter evidence
R-41290Is there a setting for "my country writes the day first". I have looked. I would pay for it.
R-41417Your software sent my mother to the dentist on the wrong day. She went anyway. They fitted her in. This is not a complaint about the dentist.
R-41514I have started telling clients the date in words. "The second Tuesday." It works. Your product is now a phone call.
R-41615Our October bookings came through for January. We are a heating company. January is when we need them. Thank you, actually.

Why the merge hid this

Decision 0001 accepted subject-only deduplication. The triage page still tells the desk to merge matching subjects and to merge when uncertain. Its interactive example already compares tenant/form causes instead. The words and executable demonstration disagree.

Subject similarity can help locate candidates, but it cannot establish a shared cause. Read the body, resolve the tenant’s locale and form, and compare the actual failure path. Matching subjects can conceal different failures; different subjects can describe the same failure. Missing tenant information or conflicting symptoms need investigation, not a forced merge into the largest ticket.

Do not rewrite accepted decision 0001. A replacement decision should record why subject-only merging failed, the evidence needed before merging, and how unresolved cases stay visible.

Received is not merged

03-3004-2705-2506-2207-2008-1709-14
received · merged into #4471 · per week

The chart separately counts when reports arrived and when the desk merged them. A merge backlog is not a sudden increase in new reports. The export records reports from April onward, including later reports after the initial merge. Known is not fixed: customers still describe missed visits, manual rescheduling, and workarounds.

Desk handoff

Keep the parser and booking-v3 hint tickets separate. Keep the evidence exceptions visible inside the parser investigation; their current routing is not proof of their mechanism. Ask for the original input, intended date, saved value, rendered invite, tenant configuration, timezone, and a reproducible sequence before declaring another root cause or a completed fix.

The proposed triage change and this review do not alter the live ticket system. The desk reports #4471 closed, with a parser fix and a separate won’t-fix outcome for the retired form. Closing this review does not establish the mechanism of every unexplained report. Recheck the current desk before quoting these historical numbers as current.

desk ref DR-70A0-P8KE