fix(dre): a transação do dia 1 parou de sumir do mês (fuso) - #40
Merged
Conversation
`transactions.data` é coluna `date`, então o supabase-js devolve a string
crua "2026-06-01" — e `new Date("2026-06-01")` é parseado como UTC pelo
ECMAScript. No fuso de Brasília isso vira 31/05 21:00:
new Date("2026-06-01").getDate() // 31
new Date("2026-06-01").getMonth() // 4 = maio
Como `fatiaDoMes` filtra por chave "YYYY-MM", a transação do dia 1 não era
encontrada em junho (virou "2026-05") nem aparecia em maio (fora do
recorte): sumia da DRE inteira. A visão DIA mostrava tudo um dia antes e a
visão SEMANA jogava segunda-feira na semana ISO anterior.
O caminho do servidor não sofria (runtime em UTC), o que criava mais uma
divergência entre mês fechado e mês aberto — a mesma família do bug da
folha.
A ingestão já estava certa: `parseFlexibleDate` constrói local. O defeito
morava só na LEITURA. Agora existe o par explícito ao lado dela:
- parseDataBanco — string de coluna `date` → meia-noite LOCAL
- formatDataBanco — Date → "YYYY-MM-DD" pelos campos locais
(`toISOString()` passa por UTC e, em fuso positivo, grava o dia anterior)
Repointadas as 5 fronteiras de leitura (useDreController, dreService,
financial-snapshot-service, visao-service, rota fechar-mes) e os 3 pontos
de escrita que passavam por `toISOString()`.
Por que nenhum teste pegava isso: a suíte ancorava as datas ao meio-dia
(`new Date(iso + "T12:00:00")`), que mascara o deslocamento. Os testes
novos usam a string CRUA do banco, com TZ=America/Sao_Paulo.
Um deles pegou um defeito no próprio helper durante o desenvolvimento: sem
âncora `$` na regex, o prefixo de um timestamp completo casava e o horário
era descartado.
Validação: 1434/1434 (155 arquivos, +16 novos) · tsc limpo em src/ ·
eslint 0 erros novos (os 2 de dreService.ts são idênticos em HEAD) ·
zero migration.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Onda 2 da auditoria da DRE. Sequência da Onda 1 (#39).
O bug
transactions.dataé colunadate, então o supabase-js devolve a string crua"2026-06-01"— enew Date("2026-06-01")é parseado como UTC pelo ECMAScript. No fuso de Brasília:Como
fatiaDoMesfiltra por chave"YYYY-MM", a transação do dia 1 não era encontrada em junho (virou"2026-05") nem aparecia em maio (fora do recorte): sumia da DRE inteira. A visão DIA mostrava tudo um dia antes; a visão SEMANA jogava segunda-feira na semana ISO anterior.O caminho do servidor não sofria (runtime em UTC) — mais uma divergência entre mês fechado e mês aberto, mesma família do bug da folha.
A correção
A ingestão já estava certa:
parseFlexibleDateconstrói local. O defeito morava só na leitura. Agora existe o par explícito ao lado dela, emsrc/lib/parsers/utils.ts:parseDataBancodate→ meia-noite localformatDataBancoDate→"YYYY-MM-DD"pelos campos locaistoISOString()passa por UTC e, em fuso positivo, grava o dia anterior — por isso o caminho de escrita também entrou.Repointadas 5 fronteiras de leitura (
useDreController,dreService,financial-snapshot-service,visao-service, rotafechar-mes) e 3 pontos de escrita.O
fechar-mesacertava por acidente (runtime em UTC); agora é determinístico — servidor e browser leem a mesma data independente do fuso da máquina.Por que nenhum teste pegava
A suíte ancorava as datas ao meio-dia (
new Date(iso + "T12:00:00")), que mascara o deslocamento. Os testes novos usam a string crua do banco, comTZ=America/Sao_Paulo:parseDataBanco— 11 casos (dia 1, round-trip dos 30 dias, virada de ano, DIA/SEMANA, idempotência, timestamp completo)montarDrePorPeriodo.fuso— 5 casos de regressão end-to-endUm deles pegou um defeito no próprio helper durante o desenvolvimento: sem âncora
$na regex, o prefixo de um timestamp completo casava e o horário era descartado.Verificação
tsclimpo emsrc/dreService.tssão idênticos emHEAD(baseline: 6 problems, 2 errors, 4 warnings)🤖 Generated with Claude Code