menzeljandClaude Opus 5
9a357d2b92
Schedule times were UTC, so a nightly 03:00 backup had to be entered as 01:00 or 02:00 depending on the season, and moved by an hour twice a year. Each schedule now has an IANA time zone, preset in the form to the browser's (e.g. Europe/Berlin), and its hour/minute/weekday are wall-clock time there. compute_next_run builds each candidate day from its date in that zone rather than adding 24 hours, so the time stays put across daylight saving changes; a time skipped by the spring change runs an hour later that day. next_run is still stored as naive UTC. - Existing schedules default to UTC and keep their run times until edited. - The API validates the zone and hour/minute/weekday ranges (400) instead of silently wrapping them. - tzdata is a dependency: the slim base image has no system tz database. Tests cover Berlin winter and summer time, both 2026 change days, the skipped hour, a weekly run across the UTC date line, hourly at a +5:30 offset, the UTC fallback and the API checks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20 lines
477 B
Plaintext
20 lines
477 B
Plaintext
fastapi==0.115.6
|
|
uvicorn[standard]==0.34.0
|
|
docker==7.1.0
|
|
sqlmodel==0.0.22
|
|
pydantic==2.10.4
|
|
pydantic-settings==2.7.1
|
|
python-jose[cryptography]==3.3.0
|
|
# Direct dependency: services/crypto_service encrypts DB-stored secrets.
|
|
cryptography==44.0.0
|
|
passlib[bcrypt]==1.7.4
|
|
bcrypt==4.2.1
|
|
python-multipart==0.0.20
|
|
watchdog==6.0.0
|
|
httpx==0.28.1
|
|
PyYAML==6.0.2
|
|
paramiko==3.5.0
|
|
boto3==1.35.99
|
|
# Time zones for backup schedules: the slim base image has no system tz database.
|
|
tzdata==2026.4
|