The homepage shows "114 days until lockdown", but the same countdown banner (banner.js) embedded on another site shows "112d 12h 16m 35s" at the same moment - a ~1.5 day gap.
Root cause: src/layouts/Landing.astro computes daysLeft from new Date() in the component frontmatter, which runs once at build time (Astro static output -> GitHub Pages), then gets baked into the static HTML as a plain number. It never updates again until the next deploy. banner.js, by contrast, recomputes the same 2027-01-01T00:00:00Z deadline live in the browser on every load.
So the homepage's number is only ever as fresh as the last deploy, and silently grows staler (undercounting the real time remaining, since it was computed in the past) until someone pushes a new build.
Possible fixes:
- Compute
daysLeft client-side in the browser (like banner.js does) instead of at build time, so it's always live.
- Or, at minimum, set up a scheduled daily rebuild (e.g. a GitHub Actions cron) so the static number never drifts by more than a day.
The homepage shows "114 days until lockdown", but the same countdown banner (
banner.js) embedded on another site shows "112d 12h 16m 35s" at the same moment - a ~1.5 day gap.Root cause:
src/layouts/Landing.astrocomputesdaysLeftfromnew Date()in the component frontmatter, which runs once at build time (Astro static output -> GitHub Pages), then gets baked into the static HTML as a plain number. It never updates again until the next deploy.banner.js, by contrast, recomputes the same2027-01-01T00:00:00Zdeadline live in the browser on every load.So the homepage's number is only ever as fresh as the last deploy, and silently grows staler (undercounting the real time remaining, since it was computed in the past) until someone pushes a new build.
Possible fixes:
daysLeftclient-side in the browser (likebanner.jsdoes) instead of at build time, so it's always live.