-- ---------------------------------------------------------------------------
-- As datas de nascimento gravadas com a hora do relogio, antes do dump (D194).
--
--   docker compose exec -T mysql mysql -uroot -proot <banco> \
--     < scripts/medir-nascimento-com-hora.sql
--
-- POR QUE ISTO EXISTE. `clientes.data_nascimento` e `unidades_socios.data_nascimento`
-- sao `datetime`, e ate 05/10/2026 os dois setters (`Cliente::setDataNascimento`
-- e `UnidadeSocio::setDataNascimento`) gravavam o dia COM a hora do relogio em
-- que o cadastro foi salvo. O conserto do D194 vale do conserto em diante: o
-- que ja esta gravado continua com a hora. O efeito e pequeno, e e de leitura:
-- a idade do filtro por faixa etaria (`TIMESTAMPDIFF(YEAR, ...)`) so vira na
-- hora em que o cadastro foi salvo, e nao a meia-noite do aniversario.
--
-- DECISAO DO DONO, 06/10/2026 (lote de perguntas, pergunta 12, a opcao (a)):
-- medir na replica e, dando mais que zero, acertar na janela do corte. Medir e
-- a listagem 1, que so le, no 7 de "O que hoje bloqueia"
-- (`docs/procedimento-de-corte.md`); acertar sao os dois UPDATE comentados no
-- fim, no passo 3 do corte, DEPOIS de `pre-migracao-limpeza.sql` -- ela anula
-- as datas de `clientes.data_nascimento` anteriores a 1000-01-01, que o modo
-- estrito recusaria aqui (a coluna `anteriores_a_1000` as conta).
--
-- A COPIA NAO SERVE DE MEDIDA: o anonimizador regera as datas de nascimento, e
-- la a conta da zero com qualquer numero de horas na producao (D194). So a
-- replica diz.
--
-- NAO IMPRIME DATA NENHUMA: so contagens.
--
-- O POSTGRESQL NAO E ESTE ROTEIRO. La a coluna e `timestamptz`, no fuso de Sao
-- Paulo, e nos 45 dias em que o horario de verao comecava a meia-noite nao
-- existe: o `00:00:00` gravado aqui e lido la como 01:00-02, o mesmo dia. O
-- dono decidiu deixar assim (pergunta 13, a opcao (a)); quem repetir a
-- listagem 1 no PostgreSQL acha essas linhas como "com hora", e elas nao sao.
--
-- No MySQL o UPDATE so tira a hora: o dia fica, e rodar de novo nao muda nada.
-- Ele sobrevive a volta atras, como o resto do passo 3.
-- ---------------------------------------------------------------------------

SELECT '=== 1. QUANTAS TEM HORA (so contagens) ===' AS '';

SELECT 'clientes' AS tabela,
       COUNT(data_nascimento)                                         AS com_nascimento,
       COALESCE(SUM(TIME(data_nascimento) <> '00:00:00'), 0)          AS com_hora,
       COALESCE(SUM(data_nascimento < '1000-01-01'), 0)               AS anteriores_a_1000
  FROM clientes
UNION ALL
SELECT 'unidades_socios',
       COUNT(data_nascimento),
       COALESCE(SUM(TIME(data_nascimento) <> '00:00:00'), 0),
       COALESCE(SUM(data_nascimento < '1000-01-01'), 0)
  FROM unidades_socios;

SELECT '=== 2. OS COMANDOS, PARA CONFERIR ANTES DE RODAR ===' AS '';

-- So se a listagem 1 deu `com_hora` maior que zero, e com `anteriores_a_1000`
-- em zero -- no passo 3, depois da limpeza, ele e zero em `clientes`; em
-- `unidades_socios` a limpeza nao passa, e uma linha assim e do dono.
--
-- DESCOMENTE PARA EXECUTAR:
--
-- UPDATE clientes
--    SET data_nascimento = DATE(data_nascimento)
--  WHERE data_nascimento IS NOT NULL
--    AND TIME(data_nascimento) <> '00:00:00';
--
-- UPDATE unidades_socios
--    SET data_nascimento = DATE(data_nascimento)
--  WHERE data_nascimento IS NOT NULL
--    AND TIME(data_nascimento) <> '00:00:00';

SELECT 'Os UPDATE estao comentados no fim deste arquivo. Confira a listagem antes.' AS '';