Skip to content

fix(deploy): el servicio decide «hoy» en la zona de Bogotá, no en UTC - #98

Merged
JoseSerpaCode merged 2 commits into
mainfrom
chore/tz-produccion
Oct 18, 2026
Merged

JoseSerpaCode merged 2 commits into
mainfrom
chore/tz-produccion

Conversation

@JoseSerpaCode

Copy link
Copy Markdown
Owner

Qué pasaba

La app decide qué día es hoy con la zona del proceso. Lo usan vencida() y hoyLocal() (el rojo de «vencida» en las tarjetas que pinta el servidor y el contador de vencidas del Hub) y, desde #97, el día de la foto diaria del burndown. deploy/forge-os.service no fijaba ninguna zona, y una VM de GCP viene en UTC. Así que desde las 19:00 en Bogotá, el HTML servido marcaba como vencida una entrega de hoy. El navegador lo corrige al repintar, pero lo primero que se ve está mal.

Cambios

  • deploy/forge-os.service: Environment=TZ=America/Bogota, con un comentario que explica el motivo. Va en el unit y no en /etc/forge-os.env porque no es un secreto ni cambia entre máquinas, y así queda en el repositorio. Es la misma zona con la que corren las pruebas e2e (fix: las fechas de entrega salían un día antes al oeste de UTC #96).
  • deploy/README.md: una sección «La zona horaria» en el paso de systemd. Explica qué depende de la zona y qué no: las marcas de CURRENT_TIMESTAMP siguen en UTC, y las fechas de entrega son días del calendario. Explica también por qué se cambia en el unit y no en la VM, y cómo comprobar que el proceso la tiene. En «Comprobar que salió bien» hay una comprobación más.

⚠️ Paso manual en la VM ya desplegada

scripts/deploy.sh reinicia el servicio pero no vuelve a copiar el unit, así que fusionar esto no cambia nada en producción hasta hacer, una vez:

sudo cp /opt/forge-os/deploy/forge-os.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl restart forge-os

Y comprobarlo:

sudo cat /proc/$(systemctl show -p MainPID --value forge-os)/environ | tr '\0' '\n' | grep '^TZ='

Comprobado

  • systemd-analyze verify acepta la línea nueva.
  • npx vitest run: 350/350 (incluye changelog.test.ts). No toca código de la app, así que no he lanzado los e2e.

Fuera de este PR

systemd-analyze verify avisa de algo que ya estaba: StartLimitIntervalSec en [Service] se ignora (va en [Unit]). El límite de «5 fallos en 60 s» que describe el comentario usa en realidad el intervalo por defecto de 10 s.

Versión

1.28.4: va después de #96 (1.28.2) y #97 (1.28.3). Si este entra antes, el CHANGELOG y package.json chocarán con ellos y habrá que renumerar.

🤖 Generated with Claude Code

JoseSerpaCode and others added 2 commits October 18, 2026 14:33
`vencida()`, `hoyLocal()` y la foto diaria del burndown usan la zona del
proceso, y el unit no fijaba ninguna: en la VM de GCP corría en UTC, así
que desde las siete de la tarde en Bogotá el HTML servido marcaba como
vencidas las entregas de hoy. El unit fija ahora TZ=America/Bogota, la
misma zona de las pruebas e2e.

deploy.sh no reinstala el unit, así que el README explica el paso único
para una instancia ya desplegada y cómo comprobar que el proceso la tiene.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts:
#	CHANGELOG.md
#	package-lock.json
#	package.json
@JoseSerpaCode
JoseSerpaCode merged commit 42b30ea into main Oct 18, 2026
1 check passed
JoseSerpaCode added a commit that referenced this pull request Oct 18, 2026
El #98 entró antes y se quedó con la 1.28.4. Este cambio pasa de la 1.28.3
de su PR a la 1.28.5, para que la versión suba en el orden en que entran
los cambios. El CHANGELOG anota que la 1.28.3 no existió.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@JoseSerpaCode
JoseSerpaCode deleted the chore/tz-produccion branch October 19, 2026 15:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant