Schedules were always evaluated in UTC because schedule.Next uses the location of lastScheduleTime, which the API returns in UTC. A CronJob with spec.timeZone set was therefore reported as not running every day. For example, Paidit's prod/dayclose runs at 0 7 * * * Europe/Stockholm: it ran at 05:00Z, but cron-checker expected 07:00Z and alerted every minute from 09:02 local time.
Convert since to the CronJob's spec.timeZone before computing the next run. CronJobs without a timeZone behave as before.
An invalid time zone returns an error, the same way an invalid schedule does.
Embed time/tzdata, because the image is FROM scratch and has no zoneinfo.
Tests: an invalid time zone, and a time-zone case that fails without the fix.
Bumped golang.org/x/net to v0.60.0. govulncheck was already failing on main with five x/net advisories, which blocks the build job.
Bumped the go toolchain to 1.27.2 for eight stdlib advisories. This is the same change as Renovate #427, which will close once this is merged.
Schedules were always evaluated in UTC because `schedule.Next` uses the location of `lastScheduleTime`, which the API returns in UTC. A CronJob with `spec.timeZone` set was therefore reported as not running every day. For example, Paidit's `prod/dayclose` runs at `0 7 * * *` Europe/Stockholm: it ran at 05:00Z, but cron-checker expected 07:00Z and alerted every minute from 09:02 local time.
- Convert `since` to the CronJob's `spec.timeZone` before computing the next run. CronJobs without a `timeZone` behave as before.
- An invalid time zone returns an error, the same way an invalid schedule does.
- Embed `time/tzdata`, because the image is `FROM scratch` and has no zoneinfo.
- Tests: an invalid time zone, and a time-zone case that fails without the fix.
- Bumped golang.org/x/net to v0.60.0. govulncheck was already failing on main with five x/net advisories, which blocks the build job.
- Bumped the go toolchain to 1.27.2 for eight stdlib advisories. This is the same change as Renovate #427, which will close once this is merged.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01C8SW6vsbkrTKjLNatQ8JTg
Schedules were always evaluated in UTC, so a cronjob with timeZone set (e.g. 0 7 * * * Europe/Stockholm) was reported as not running every day. Embed tzdata since the image is built from scratch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C8SW6vsbkrTKjLNatQ8JTg
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Schedules were always evaluated in UTC because
schedule.Nextuses the location oflastScheduleTime, which the API returns in UTC. A CronJob withspec.timeZoneset was therefore reported as not running every day. For example, Paidit'sprod/daycloseruns at0 7 * * *Europe/Stockholm: it ran at 05:00Z, but cron-checker expected 07:00Z and alerted every minute from 09:02 local time.sinceto the CronJob'sspec.timeZonebefore computing the next run. CronJobs without atimeZonebehave as before.time/tzdata, because the image isFROM scratchand has no zoneinfo.🤖 Generated with Claude Code
https://claude.ai/code/session_01C8SW6vsbkrTKjLNatQ8JTg