Repository navigation
spec(AST-111): date components use the calendar the application chooses - #9605
nynexman4464 wants to merge 12 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved. spec:AST-111 adds requirements that no current record states, and it replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters. An engineering owner records that decision by commenting /approve-spec c3b60c918a83af4e23d4b1daaa003b6f9e236e1c on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-6, including the Gregorian changes to Shift+PageUp/PageDown, onChange timing and parseDateInput; the author may do so as an engineering owner. Whatever that decision is, the record also needs these fixes:
- FR15 gives explicit
presentation="native"the Astryx surface, which contradictsspec:AST-043FR2, so keepnativenative or list AST-043 as amended. - FR5 promises the same markup when both sides have
Temporal, but with FR19's polyfill advice a native server and a polyfilled browser can lay outchineseanddangimonths differently, sospec:AST-013FR9 is not preserved. - The Gregorian behaviour changes (FR7, FR12, AR3 and
parseDateInput) need aspec:AST-017compatibility class in Current-state impact, and DEC-1 should not say existing callers are unaffected. - FR18 should name each date helper that gains a calendar option.
[Automated review]
| - **FR15 — Other calendars use the Astryx picker.** `<input type="date">` is | ||
| Gregorian by specification. With a calendar other than `gregory` or `iso8601`, | ||
| `presentation="adaptive-native"` resolves to `adaptive-bottom-sheet`, and | ||
| `presentation="native"`, or the deprecated `nativePicker="always"`, uses the |
There was a problem hiding this comment.
This sends explicit presentation="native" to the Astryx surface. spec:AST-043 FR2 says explicit native "MUST always show the native surface, with no eligibility fallbacks", and AST-043 is not in Current-state impact. Keep native native and limit the fallback to adaptive-native and legacy nativePicker="always", or list AST-043 FR1–FR2 as amended.
| The component resolves its calendar before its first render, so a server and | ||
| a browser that both have `Temporal`, or both lack it, render the same markup. |
There was a problem hiding this comment.
FR19 advises loading a polyfill only where Temporal is missing, so a Node.js 26 server (native) and iOS Safari (polyfill) both have Temporal. FR19 also says those two can start nine Chinese and four Korean months a day apart, so the hydrating render can differ from the server markup, which spec:AST-013 FR9 forbids. The exception below lists FR9 as preserved. Name this mixed-runtime case and what the component does in it.
| **Decider:** `nynexman4464`, 2026-11-02 | ||
|
|
||
| The calendar changes presentation and input only, so application data, forms, | ||
| servers, and existing callers are unaffected. Date libraries and platforms that |
There was a problem hiding this comment.
"existing callers are unaffected" doesn't hold for Gregorian callers: FR7 changes Shift+PageUp/PageDown, FR12 changes when onChange fires, AR3 changes rejection messages, and parseDateInput loses its Date fallback. Please list these in Current-state impact with their spec:AST-017 class, and narrow this sentence to stored values.
| `system_*` formats do not change. Pure date helpers keep a Gregorian default | ||
| and an explicit calendar option; Astryx call sites pass the resolved calendar. |
There was a problem hiding this comment.
Which pure date helpers gain the calendar option? The public candidates are plainDateFormat, formatSharedDate, and the charts formatters shortDate and monthYear. Naming them in the Public contract gives the implementation's API changes a record to match.
…ility classes, named helpers
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states and replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters. An engineering owner records that decision by commenting /approve-spec ef172d33b9aa5266bad9447b0a371d38ba0fe9e2 on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-6, including the Gregorian changes to Shift+PageUp/PageDown, onChange timing and typed parsing; the author may do so as an engineering owner. Whatever that decision is, three record fixes remain:
- The
spec:AST-013FR12 exception lists FR9 as preserved, but a server and browser that differ onTemporal(a Node.js server older than 26 with Chrome 144 and no polyfill, say) hydrate different markup for everyTemporalcalendar, so name that case or keep the server's resolution through hydration. - FR7's year step cites
spec:AST-017FR53, butcomponent:CalendarAR1 adopts the APG Grid pattern with PageUp/PageDown by a month, so classify it under FR3/FR5 or amend AR1 first. - The Gregorian change list says no caller changes, yet
1/5/26in a day-first locale commits 1 May 2026 instead of today's 5 January 2026, so list the two-digit-year order change with its class.
[Automated review]
| once in development, on the server and in the browser, naming the polyfill. | ||
| The component resolves its calendar before its first render, so a server and | ||
| a browser that both have `Temporal`, or both lack it, render the same markup, | ||
| except in FR19's mixed-runtime case. |
There was a problem hiding this comment.
A server and browser where only one side has Temporal also render different markup: a Node.js server older than 26 renders Gregorian, and Chrome 144 renders the selected calendar in the hydrating render, for every Temporal calendar. spec:AST-013 FR9 forbids that, and the exception below lists FR9 as preserved outside the Chinese and Korean case. Name the one-sided case, or keep the server's resolution through hydration and switch after it.
| control cannot express, and an explicit `presentation="native"` stays native. | ||
| - Gregorian behavior that changes, with its `spec:AST-017` class: | ||
| - FR7's Shift+PageUp and Shift+PageDown year step conforms the grid to the APG | ||
| date picker pattern: an accessibility behavior fix (FR53). |
There was a problem hiding this comment.
spec:AST-017 FR53 covers the required parts of an APG pattern the component adopts under spec:AST-020 FR15. component:Calendar AR1 adopts the APG Grid pattern with "PageUp and PageDown by a month"; the date picker is an APG dialog example. Shift+Page is undocumented today, so this is nonbreaking under FR3/FR5, or AR1 can adopt the year step first.
| rejects (FR5). | ||
| - `parseDateInput` in `@astryxdesign/core/utils` does not change, and the | ||
| Gregorian text field still commits any text it reads (FR9), so no caller | ||
| changes. |
There was a problem hiding this comment.
FR9's fallback covers only text that matches none of its forms. 1/5/26 matches the numeric form, so in en-GB it commits 1 May 2026, where parseDateInput falls through to new Date and commits 5 January 2026 today. Please list this two-digit-year order change here with its class, and say whether FR11 or FR9's fallback wins for numeric text invalid in the locale's order, such as 13/5/2026 in en-US.
…the bottom sheet follows the calendar
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states, replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters, and amends spec:AST-043 FR2 so that a non-Gregorian calendar overrides an explicit presentation="native". An engineering owner records that decision by commenting /approve-spec e915e2f75f6cd9b482db6c1c57a45ce71281fd8b on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-7, including the Gregorian changes to Shift+PageUp/PageDown, onChange timing, typed parsing and out-of-range text; the author may do so as an engineering owner. Whatever that decision is, three record fixes remain:
- The
spec:AST-013FR12 exception lists FR9 as preserved, but a server and browser where only one side hasTemporal(for example a Node.js server older than 26 with no polyfill, serving Chrome 144) hydrate different markup for everyTemporalcalendar, so name that case or keep the server's resolution through hydration. - FR7's year step is classed as a
spec:AST-017FR53 fix, butcomponent:CalendarAR1 adopts the APG Grid pattern with PageUp/PageDown by a month and no year step (onlycomponent:DateInputAR8 names it), so have Calendar AR1 adopt it first or class the Calendar half under FR3. - The Gregorian change list says no caller changes, yet
1/5/26in a day-first locale commits 1 May 2026 instead of today's 5 January 2026, so list the two-digit-year order change with its class and say which rule wins for numeric text that is invalid in the locale's order.
Two smaller points: the AST-043 amendment line should also cover the new adaptive-native and nativePicker fallback and DateTimeInput's time segment, and FR19 and Platform support should name the Temporal capability instead of hand-written browser versions.
[Automated review]
… takes the selected date's era
…dar only when it differs; two-digit years and swapped orders
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states, replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters, and amends spec:AST-043 FR1–FR3 so that a non-Gregorian calendar overrides an explicit presentation="native". An engineering owner records that decision by commenting /approve-spec db790f8f9a89f837161006577ec81c108ad04983 on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-7, including the Gregorian changes to Shift+PageUp/PageDown, onChange timing, short typed years and out-of-range text; the author may do so as an engineering owner. Whatever that decision is, three fixes remain:
- FR5's Gregorian fallback applies to any component that resolves a
Temporalcalendar, which FR18 makes Timestamp and PowerSearch do, but only Calendar, DateInput, DateRangeInput and DateTimeInput get thespec:AST-013FR12 exception, so add those two to it or limit FR5's fallback to the four input components and say that FR18's formats need noTemporal. - The Gregorian change list names only the day-first two-digit-year change, yet in month-first locales
1/5/46would commit 1946 instead of today's 2046 and1/5/2(today 2002) has no rule, so list the window change and say how a one-digit year reads. - The description's Gregorian compatibility list still calls the Shift+Page year step an FR53 accessibility fix and leaves out the out-of-range-text and two-digit-year changes, while the record classes the step under AST-017 FR3/FR5 and lists both, so update the description to match the record.
Three smaller points are optional: the FR7 class line says Calendar AR1 names the year step when only DateInput AR8 does today, the FR11 line cites AST-017 FR5 for a change to DateTimeInput's documented revert, and FR15 leaves DateTimeInput's time segment under an explicit native open.
[Automated review]
| and work in every supported environment. The other calendars use the | ||
| runtime's `Temporal`, native or loaded by the application as a polyfill. | ||
| Astryx bundles no polyfill. Where `Temporal` is missing, a component that | ||
| resolves one of those calendars renders and accepts Gregorian dates and warns |
There was a problem hiding this comment.
FR18 has Timestamp, PowerSearch and the chart formatters resolve the provider calendar, so this fallback reaches them too. Timestamp is SSR-capable with no spec:AST-013 FR12 exception, and its FR3 requires hydration without a mismatch, but the exception below covers only Calendar, DateInput, DateRangeInput and DateTimeInput. Either add Timestamp and PowerSearch to the exception, or limit this fallback to the four input components and say FR18's formats render every FR1 calendar through Intl without Temporal.
| does not change in either case: a nonbreaking interaction change (FR5). | ||
| - `parseDateInput` in `@astryxdesign/core/utils` does not change, and the | ||
| Gregorian text field still commits any text it reads (FR9). | ||
| - A two-digit year follows the locale's field order: `1/5/26` in `en-GB` |
There was a problem hiding this comment.
This names only the day-first case. In month-first locales the latest stable release hands short years to native Date (pivot 1950–2049), so 1/5/46 in en-US commits 2046 today and 1946 under FR10's window, and 1/5/2 commits 2002 today with no rule here (FR10 and DEC-4 read years literally; FR12 names Enter-or-blur commits only for two-digit years). Please list the window change with its class and say whether a one-digit year is read literally or rejected.
…r-support exception; short Gregorian years
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states, replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters, and amends spec:AST-043 FR1–FR3 so that a non-Gregorian calendar overrides an explicit presentation="native". An engineering owner records that decision by commenting /approve-spec d77c1792a2a6121b93ecac6233caa69c44d71fcb on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-7, including the Gregorian changes to Shift+PageUp/PageDown, onChange timing, short typed years and out-of-range text; the author may do so as an engineering owner. Whatever that decision is, three fixes remain:
- FR9 and Current-state impact promise that the Gregorian field still commits all text
parseDateInputreads, and the FR9–FR14 Verification row fails if it stops, yet the new one-digit rule refuses1/5/2, whichparseDateInputreads as 5 January 2002, so carve the one-digit year out of those three places and the description, or drop the rule. - Platform support now gives Timestamp and PowerSearch the
spec:AST-013FR12 exception, but Current-state impact still records it for only Calendar, DateInput, DateRangeInput and DateTimeInput, so addcomponent:Timestampandcomponent:PowerSearchto that line. - The year-step line credits
component:CalendarAR1 with naming the Shift+Page year step, which onlycomponent:DateInputAR8 does, and the short-year lines say no record documents theDatereading althoughcomponent:DateInputFR6 records it as an implementation gap, so correct both citations.
Three smaller points are optional: FR18 says chart date formatters follow the provider's calendar although shortDate and monthYear are pure helpers with a Gregorian default, the FR11 line classes the out-of-range-text change under spec:AST-017 FR5 despite DateTimeInput's documented revert, and FR15 leaves DateTimeInput's time segment under an explicit native open.
[Automated review]
| the Gregorian calendar, text that matches none of these forms, or that names a | ||
| date the locale's numeric order does not have, still commits on Enter or blur | ||
| when `parseDateInput` reads it: `13/5/2026` in `en-US` commits 13 May 2026. | ||
| Otherwise FR11 applies. A one-digit year is not a date. |
There was a problem hiding this comment.
parseDateInput, which the record keeps unchanged, reads 1/5/2 in en-US as 5 January 2002, so the fallback two lines up commits it while this sentence refuses it; Current-state impact ("still commits any text it reads") and the FR9–FR14 Verification failure ("Gregorian text that parseDateInput reads stops committing") say the same as the fallback. Carve the one-digit year out of all three, for example "still commits any text it reads, except a one-digit year", or drop this rule.
| - `component:Calendar`, `component:DateInput`, `component:DateRangeInput`, and | ||
| `component:DateTimeInput` add the `calendar` prop, project FR4–FR17 and | ||
| AR1–AR3, and record the `spec:AST-013` FR12 exception. | ||
| - `component:Timestamp` and the PowerSearch, Schedule, and chart formatters |
There was a problem hiding this comment.
Platform support now has Timestamp and PowerSearch record the spec:AST-013 FR12 exception, but this line only has them follow FR18, and no PowerSearch record is named. Add component:Timestamp and component:PowerSearch to the line that records the exception.
| - Gregorian behavior that changes, with its `spec:AST-017` class: | ||
| - FR7's Shift+PageUp and Shift+PageDown year step gives keys with no | ||
| documented behavior the APG date picker's year step, which | ||
| `component:Calendar` AR1 names as an exception: nonbreaking (FR3, FR5). |
There was a problem hiding this comment.
component:Calendar AR1 binds only "PageUp and PageDown by a month" and names no Shift+Page exception; component:DateInput AR8 names the year step, for the touch scroller. Cite DateInput AR8, or say Calendar AR1 documents no Shift binding; the nonbreaking class still holds.
| - In month-first locales a two-digit year reads within FR10's window, where | ||
| the latest stable release uses the runtime's `Date` parsing: in 2026, | ||
| `1/5/46` to `1/5/49` in `en-US` commit 1946 to 1949 instead of 2046 to 2049. | ||
| No record documents the `Date` reading: nonbreaking (FR3). |
There was a problem hiding this comment.
component:DateInput FR6 on main records this reading as an implementation gap: "In a month-first locale, numeric text outside the locale-ordered forms (such as 1/5/25) still falls back to the browser's month-first reading". Cite that gap and class this line and the one-digit line as a spec:AST-017 FR5 restoration of FR6, which stays nonbreaking.
…p and PowerSearch in Current-state impact; cite DateInput FR6
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states, replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters, and amends spec:AST-043 FR1–FR3 so that a non-Gregorian calendar overrides an explicit presentation="native". An engineering owner records that decision by commenting /approve-spec 7cade50e286384cfa091d7befbf568049b6b5e77 on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-7, including the Gregorian changes to onChange timing, short typed years and out-of-range text; the author may do so as an engineering owner. Whatever that decision is, two fixes remain:
- FR15 and DEC-7 send an explicit
presentation="native"to the popover or the bottom sheet, whicharchitecture:public-component-apiINV16 rules out ("a caller's explicit choice always wins over that default"), so add INV16 to Current-state impact with the calendar exception, or resolve an explicitnativeto one surface on every pointer. - The Current-state impact line for Shift+PageUp and Shift+PageDown calls them keys with no documented behavior, but
component:CalendarAR1 onmainnow binds them to a year step and the Shift+Page bug is closed, so say that Calendar already steps a Gregorian year and that FR7 extends the step to calendar years and leap months, and update the description to match.
Four smaller points are optional: state FR7's day clamp for the year step as Calendar AR1 does, name component:DateTimeInput's revert row in the FR11 line, align the FR18 Verification row with chart helpers that follow only their calendar argument, and say whether DateTimeInput's time segment stays native under adaptive-native.
[Automated review]
| other than `gregory` or `iso8601`, every presentation that shows the native | ||
| control uses the Astryx surface instead: the popover on a fine pointer and the | ||
| bottom sheet on a coarse pointer. This covers `adaptive-native`, the default, | ||
| the deprecated `nativePicker` values, and an explicit `presentation="native"`, | ||
| which also warns in development. |
There was a problem hiding this comment.
This sends an explicit presentation="native" to the popover or the bottom sheet by pointer type. architecture:public-component-api INV16 says a component's touch behavior is its default "and a caller's explicit choice always wins over that default", and Current-state impact amends only spec:AST-043 FR1–FR3. Add INV16 to Current-state impact with this calendar exception, or resolve an explicit native to one Astryx surface on every pointer.
| - FR7's Shift+PageUp and Shift+PageDown year step gives keys with no | ||
| documented behavior the APG date picker's year step, which | ||
| `component:Calendar` AR1 names as an exception: nonbreaking (FR3, FR5). |
There was a problem hiding this comment.
component:Calendar AR1 on main now binds "Shift+PageUp and Shift+PageDown by a year (a named exception, as in the APG date picker dialog; a day the target month lacks clamps to its last day)", and component:DateInput AR8 states the step for the touch scroller, so these keys are documented. Say that Calendar already steps a Gregorian year and that FR7 extends the step to calendar years and leap months; FR7 could also state the same day clamp.
…t for that calendar
There was a problem hiding this comment.
This draft spec needs an engineering owner's decision before it can be approved: spec:AST-111 adds calendar-system requirements that no current record states, replaces architecture:internationalization INV10's Gregorian-only grids, navigation, parsing and formatters, and amends spec:AST-043 FR1–FR3. An engineering owner records that decision by commenting /approve-spec 9400c9ee89261a01710b5181f8b1b0fcb9724353 on this pull request, approving or amending FR1–FR19, AR1–AR3 and DEC-1–DEC-7; the author may do so as an engineering owner.
These need changes whatever the decision:
- The new Current-state impact line classes the explicit
-u-ca-switch as nonbreaking, but an app that renderslocale="th-TH-u-ca-buddhist"today sees Gregorian dates and must addcalendar="gregory"to keep them, which is breaking underspec:AST-017FR1, so class it breaking withcalendar="gregory"as the restoring prop or keep a released-u-ca-locale Gregorian until the application setscalendar. - FR15 and DEC-7 override an explicit
presentation="native", whicharchitecture:public-component-apiINV16 says always wins, yet Current-state impact amends onlyspec:AST-043, so add INV16 there with the calendar exception. - The Shift+Page line says FR7 gives "keys with no documented behavior" a year step, but
component:CalendarAR1 onmainalready binds Shift+PageUp and Shift+PageDown to a year, so say FR7 extends that step to calendar years and leap months and update the description to match.
[Automated review]
| - A provider locale with an explicit `-u-ca-` keyword, which the latest stable | ||
| release shows in Gregorian, shows that calendar in `Calendar`, the date | ||
| inputs, and FR18's formats. The keyword is the application's explicit request | ||
| for the calendar (DEC-2): nonbreaking (FR5), and `calendar="gregory"` keeps | ||
| Gregorian. |
There was a problem hiding this comment.
An app that renders locale="th-TH-u-ca-buddhist" today gets Gregorian Timestamps and types Gregorian years (component:Timestamp FR2: "with Gregorian years"). Under FR2 and FR10 it shows Buddhist 2569 and commits a typed 2026 as Gregorian 1483, and keeping the released output takes calendar="gregory". spec:AST-017 FR1 calls that breaking ("must change source or configuration to keep its … data, semantic output … working"), and FR6 says few affected callers does not change the class. Class it breaking with calendar="gregory" as the restoring prop (spec:AST-017 FR3), or keep a released -u-ca- locale Gregorian until the application sets calendar.
Exact decision needed
Whether Astryx date components support calendar systems other than Gregorian, and if so the observable contract. That covers how the calendar is selected, what values are, where calendar structure comes from, typed entry, presentations, shared formatters, the
Temporalboundary, the Chinese and Korean caveat, and the browser-support exception.Existing authority searched
architecture:internationalizationINV10 makes date semantics Gregorian only. Its change-coupling section names non-Gregorian component semantics as a human API decision that an implementation PR can't make, and this record is that decision. INV10 stays the architecture owner and is rewritten when this ships (see Current-state impact). INV8 and INV9 (shared helpers, deterministic defaults) are kept.component:InternationalizationProvider,Calendar,DateInput,DateRangeInput,DateTimeInput,Timestamp): none defines non-Gregorian behavior.spec:AST-013: FR3 names iOS Safari, and FR5 requires full behavior. FR12 is the exception mechanism used here.spec:AST-043owns input presentations. FR15 only resolves which presentation applies for non-Gregorian calendars.spec:AST-067lists other calendars as a non-goal. Wall-time resolution is unchanged.plainDate,InternationalizationProvider, persian, jalali, hebrew, hijri.max), feat(core): wire the translator adapter into i18n #4404 (translator adapter). None of them decides calendar systems; the implementation PRs will rebase over whichever lands first.onChangefires with month-first dates while typing) are covered by FR7 and FR12.Decision
calendarprop, then the provider'scalendarprop, then an explicit-u-ca-in the locale, thengregory. A barefa-IRstays Gregorian (FR2), and Gregorian stays the default.Temporaldoes all calendar arithmetic. Gregorian-aligned calendars (gregory, iso8601, buddhist, roc, japanese) need noTemporal. The others use nativeTemporalor a polyfill the application loads on the server and in the browser. Without it, those calendars fall back to Gregorian with a development warning (FR5).Intlwrites it for the locale and calendar.onChangefires once per complete date.presentation="native", which also warns (DEC-7, an amendment to AST-043 FR2).DateRangeInputrenders in the calendar, without typed entry.formatSharedDateand the chartsshortDate/monthYeargain an optionalcalendarargument.Temporal, with a documented caveat (FR19). That includes the mixed-runtime hydration case, which the AST-013 exception names.onChangetiming and the AR3 messages are FR5 nonbreaking changes.1/5/26inen-GBis 1 May, not 5 January): a fix (FR5). In month-first locales it reads within FR10's window, so in 20261/5/46to1/5/49commit 1946 to 1949 instead of the runtimeDatereading 2046 to 2049.component:DateInputFR6 records thatDatefallback as a gap, so this restores FR6: nonbreaking (FR5).parseDateInputis unchanged. The Gregorian field still commits any text it reads, except a one-digit year, including text the new forms read as a date the locale's order doesn't have (13/5/2026inen-UScommits 13 May 2026).1/5/2no longer commits the runtimeDatereading of 2002, which also restores DateInput FR6: nonbreaking (FR5).Temporal. Server rendering needsTemporalon the server too.Rejected alternatives
fa,th,ar-SA, and similar locales.Intl-only engine was prototyped and matchedTemporal, but correctness and maintenance belong with the platform.Intldata, which makes native environments less consistent.Claim scope and non-goals
The record governs only FR1–FR19 and AR1–AR3. Out of scope:
Evidence and implementation relationship
Temporalfor all 16 calendars.@internationalized/dateand nativeTemporalin Chromium and Firefox. The exceptions are the Chinese and Korean engine differences that FR19 documents.Temporal, and withTemporalremoved and a polyfill loaded. The fallback checks pass withTemporalremoved and no polyfill.Writing rubric results
Screenshots
From the implementation PRs:
fa-IR)Scope
Temporaland the polyfill entry are named because applications load them.)Validation
pnpm check:knowledge: passesgit diff --check: clean