---
fonte: 01-canonicos/seed-componentes.md
versao_da_fonte: v1.67
secao: h13
titulo: "Histórico da seção §13 — Date picker (não é regra)"
status: historico
vigente_desde: null
superseded_by: null
tipo_de_fatia: historico
secao_mae: 13
quando_consultar: "Histórico da §13 — NÃO é regra; leia só se a pergunta for sobre o passado (quando e por que a decisão mudou)."
em_uma_frase: null
nao_cobre: null
conceitos: null
vocabulario: null
sequencia: 28 de 172
bytes_do_corpo: 974
md5_do_corpo: 7fcc6b08ae240e5733c5c864c8702779
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-componentes.md
---
### Histórico da seção

> **Base (3 rodadas):** R1 — GOV.UK/NHS/NSW date input (memoráveis digitadas; NUNCA auto-advance; ano 4 dígitos), CMS (single-input flexível formata no blur), Scottish (calendar = progressive enhancement). R2 — shadcn Calendar/react-day-picker (locale pt-BR, range 2 meses, presets — ReUI), GitLab (digitar OU escolher, sempre). R3 — NN/g date input (picker frustra data distante: "165 cliques até 1990"), Baymard touch keyboards, icapps (picker inadequado p/ nascimento), Smashing birthday. M1–M6 conferidas no consolidado.

**Alternativa descartada com contexto (M2):** os 3 campos separados do GOV.UK resolvem a ambiguidade dd/mm × mm/dd do mundo anglófono — o dd/mm/aaaa universal brasileiro não tem essa ambiguidade na mesma escala, e a máscara B5 já testou. Plano B documentado: se pesquisa com usuários SEED mostrar erro de formato, os 3 campos entram (com type=text inputmode=numeric — E1 vale lá também).