Found while implementing #7443 (giving the datetime display convention one home). Source-confirmed on origin/main 1bae75bb. Filing unassigned — recording, not claiming.
The claim
#7443's ruling converged the datetime half of formatCellValue (packages/components/src/renderers/complex/data-table.tsx) onto formatDateTime. That function sniffs an ISO string and branches on whether it carries a T. The date-only branch was deliberately left alone in that PR, and it is a second display convention for date in exactly the way #7443 described for datetime:
// data-table.tsx, the date-only branch
new Intl.DateTimeFormat(language, { year: 'numeric', month: 'short', day: 'numeric' })
versus formatDate's default in packages/core/src/utils/date-display.ts, which drops the year inside the current year on purpose:
const isCurrentYear = date.getFullYear() === new Date().getFullYear();
return date.toLocaleDateString(options?.locale, {
year: isCurrentYear ? undefined : 'numeric',
month: 'short',
day: 'numeric',
});
Measured, en-US, for a date in the current year:
| path |
renders |
date field cell (DateCellRenderer -> formatDate) |
Jul 4 |
data-table date-only cell (formatCellValue) |
Jul 4, 2026 |
For a past year the two agree (Jul 4, 2024), which is why this is easy to miss: it diverges only for the dates users look at most.
Why this is worth a card
Same mechanism as #7443 and objectui#4576 — two Intl option bags for one concept, kept in step by nothing — and the year-dropping rule is a deliberate product decision (the formatDate comment cites Salesforce / HubSpot / Linear crowding out in-progress records) that one of the two paths simply does not implement.
Why it was NOT fixed in #7443's PR
Scope, and a stop-condition. #7443's ruling named the datetime convention and required that no pixel move in data-table; routing the date-only branch through formatDate would move one (Jul 4, 2026 -> Jul 4) on every current-year date in every data-table. That is a separate visible change and needs its own decision, which is what this card is for.
Open question for whoever triages it
Which is right for a table cell? formatDate's year-dropping is tuned for cards and list cells where the year is noise; a data-table column of mixed-year dates arguably wants the year on every row so the column reads consistently. Answering "converge them" without answering that would just pick one silently.
Grading
Observation-class. Both faces are locale-correct and no data is lost or misread. The reusable half is the undocumented second convention, not a user-facing defect.
Found while implementing #7443 (giving the
datetimedisplay convention one home). Source-confirmed onorigin/main1bae75bb. Filing unassigned — recording, not claiming.The claim
#7443's ruling converged the datetime half of
formatCellValue(packages/components/src/renderers/complex/data-table.tsx) ontoformatDateTime. That function sniffs an ISO string and branches on whether it carries aT. The date-only branch was deliberately left alone in that PR, and it is a second display convention fordatein exactly the way #7443 described fordatetime:versus
formatDate's default inpackages/core/src/utils/date-display.ts, which drops the year inside the current year on purpose:Measured,
en-US, for a date in the current year:datefield cell (DateCellRenderer->formatDate)Jul 4data-tabledate-only cell (formatCellValue)Jul 4, 2026For a past year the two agree (
Jul 4, 2024), which is why this is easy to miss: it diverges only for the dates users look at most.Why this is worth a card
Same mechanism as #7443 and objectui#4576 — two
Intloption bags for one concept, kept in step by nothing — and the year-dropping rule is a deliberate product decision (theformatDatecomment cites Salesforce / HubSpot / Linear crowding out in-progress records) that one of the two paths simply does not implement.Why it was NOT fixed in #7443's PR
Scope, and a stop-condition. #7443's ruling named the datetime convention and required that no pixel move in
data-table; routing the date-only branch throughformatDatewould move one (Jul 4, 2026->Jul 4) on every current-year date in every data-table. That is a separate visible change and needs its own decision, which is what this card is for.Open question for whoever triages it
Which is right for a table cell?
formatDate's year-dropping is tuned for cards and list cells where the year is noise; a data-table column of mixed-year dates arguably wants the year on every row so the column reads consistently. Answering "converge them" without answering that would just pick one silently.Grading
Observation-class. Both faces are locale-correct and no data is lost or misread. The reusable half is the undocumented second convention, not a user-facing defect.