[JoseSerpaCode]

Va encima de #96 (base fix/fechas-solo-dia), porque usa diaDeCalendario() y el deSQLite() corregido. Cuando #96 se fusione y se borre su rama, GitHub cambia la base de este PR a main él solo; si no se borra la rama, hay que cambiarla a mano antes de fusionar.

Qué estaba mal

Es el mismo fallo que en #96, en los sitios que quedaban sin revisar, y uno más que salió persiguiendo una prueba intermitente.

1. «Termina hoy» llegaba un día antes (src/pages/w/[sys_tag]/index.astro). Los días que le quedan al sprint activo se calculaban con Math.ceil((new Date(end_date) - ahora) / 86400000). Con una fecha solo-día, eso es la medianoche UTC: en Bogotá decía «termina hoy» desde las 19:00 del día anterior, y en Tokio, el último día por la mañana, todavía decía «termina en 1 día».
2. La foto diaria del burndown salía con la fecha de mañana (src/lib/sprintSnapshots.ts y el disparador diario de src/lib/db.ts). El día se tomaba con toISOString().slice(0, 10), en UTC. Desde las 19:00 en Bogotá, la foto de hoy se guardaba como la de mañana, y la del día real se quedaba como estaba a las 18:59.
3. El campo de fecha del modal se deshacía (IssueDetailsModal.astro). Al abrir un ticket, refreshTimeTrackingUI() corre dos veces: una directa y otra cuando terminan de cargar los registros de trabajo. Si la segunda respuesta llegaba después de elegir una fecha, el campo volvía a la vieja, aunque el PATCH ya hubiera guardado la nueva. Era la causa de que fecha-y-cancelar.spec.ts fallara de vez en cuando con la suite completa: en la instantánea del fallo el campo estaba enfocado y mostraba 2026-09-09.

Cambios

• diasHasta(valor, ahora) (nueva, en lib/fechas): días del calendario hasta una fecha. Da 0 si es hoy, un número negativo si ya pasó y null si no se puede leer. Resta medianoches UTC de las dos fechas del calendario, así que no se equivoca en los días de 23 o 25 horas del cambio de hora. La usa el resumen del espacio.
• La línea de tiempo de sprints del resumen lee las fechas con deSQLite() en vez de new Date(). new Date() leía una fecha solo-día como UTC y una marca de SQLite como hora local.
• Las fotos del burndown usan el día local del servidor: hoyLocal() en sprintSnapshots.ts, y el mismo cálculo en línea en db.ts. db.ts no importa lib/fechas a propósito: lo carga Node sin compilar (tests/e2e/reset-db.ts), y un import './fechas' sin extensión no resuelve, así que el servidor de pruebas no llegaba a arrancar. Está explicado en un comentario.
• El modal no reescribe el campo de fecha mientras está enfocado. Es la misma guarda que ya llevaban las horas estimadas.

Alcance real

• Hoy la interfaz crea los sprints sin fechas (POST /api/sprints solo con name) y nada crea hitos: en forge.db local no hay ninguna fecha de sprint ni ningún hito. El punto 1 solo se veía en sprints con fechas puestas por la API o por scripts/seed.mjs. El seed guarda marcas ISO con Z, y ahí el fallo era solo de redondeo de horas.
• La gráfica de Métricas solo pinta totales; la serie diaria no se dibuja todavía. El punto 2 corrige el dato guardado, no algo que hoy se vea.
• Las fechas de hito (target_date) y de fin de sprint en el resumen ya pasaban por fecha(), así que quedaron arregladas en fix: las fechas de entrega salían un día antes al oeste de UTC #96.

Pruebas

• tests/fechas-sprint.test.ts: diasHasta() y el día de la foto, en America/Bogota y Asia/Tokyo, más un caso en Europe/Madrid con el cambio de hora del 25 de octubre. Con el sprintSnapshots.ts anterior, la prueba de la foto falla en Bogotá.
• fecha-y-cancelar.spec.ts › elegir la fecha justo al abrir el ticket no se deshace: deja pasar la primera carga del ticket y retiene la respuesta de la segunda hasta después del PATCH. Sin el arreglo falla siempre (Received: "2026-09-09"); con él, pasa.
• npx vitest run: 381/381. npx playwright test: 254/254 en dos corridas completas seguidas.

Para revisar aparte: la zona del servidor en producción

vencida(), hoyLocal() y ahora las fotos usan la zona del proceso. Las pruebas e2e fijan TZ=America/Bogota, pero deploy/forge-os.service no fija ninguna, y una VM de GCP suele venir en UTC. Si el servidor de producción corre en UTC, el contador de vencidas del Hub y el color de vencida de las tarjetas servidas cambian de día a las 19:00 de Bogotá. El navegador lo corrige al repintar, pero el HTML servido no. No lo he tocado, porque es configuración de despliegue: bastaría TZ=America/Bogota en /etc/forge-os.env, o Environment=TZ=America/Bogota en el unit.

Versión 1.28.3.

🤖 Generated with Claude Code