Describe the bug
The APScheduler suddenly gives errors.
To Reproduce
Steps to reproduce the behavior, e.g.:
- add a Resource, e.g. WMS
- Wait for execution
- See error (see below)
Expected Behavior
No error.
Screenshots or Logfiles
2026-06-26 18:11:28,225 - apscheduler.executors.default - ERROR - Job "run_job (trigger: interval[0:30:00], next run at: 2026-06-26 18:41:28 CEST)" raised an exception
Traceback (most recent call last):
File "/GeoHealthCheck/lib/python3.12/site-packages/apscheduler/executors/base.py", line 131, in run_job
retval = job.func(*job.args, **job.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/scheduler.py", line 119, in run_job
if not lock.obtain(uuid, frequency):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/models.py", line 693, in obtain
if not self.has_expired():
^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/models.py", line 690, in has_expired
return now > self.end_time
^^^^^^^^^^^^^^^^^^^
TypeError: can't compare offset-naive and offset-aware datetimes
2026-06-26 18:11:28,228 - __main__ - ERROR - error_listener: EVENT_JOB_MISSED - <self.__class__.__name__ (code=8192)>
Context (please complete the following information):
- OS: any
- Browser NA
- Browser Version NA
- Python Version 3.12
- GeoHealthCheck Version master on June 26, 2026
If running with Docker:
- Docker installed version
- GeoHealthCheck Docker Image version : latest
**Analysis
I suspect this happens since tzlocal upgrade to latest version related to APScheduler. The previous was tzlocal<3.0
Now:
tzdata 2025c hc9c84f9_1 conda-forge
tzlocal 5.4.3 pypi_0 pypi
See YelpArchive/elastalert#2968
Plus seems to happen only on existing databases, i.e. jobs stored.
Suspect difference/mismatch between: "Offset-naive and Offset-aware datetimes".
Newly added jobs work ok, like this local instance:
2026-06-26 19:21:18,133 - apscheduler.executors.default - INFO - Running job "run_job (trigger: interval[0:10:00], next run at: 2026-06-26 19:31:18 CEST)" (scheduled at 2026-06-26 19:21:18.127902+02:00)
2026-06-26 19:21:18,139 - scheduler - INFO - 1 No Lock at all: obtain new
2026-06-26 19:21:18,155 - GeoHealthCheck.probe - INFO - Requesting: GET url=https://service.pdok.nl/kadaster/adressen/wms/v1_0
2026-06-26 19:21:18,162 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): service.pdok.nl:443
2026-06-26 19:21:18,257 - urllib3.connectionpool - DEBUG - https://service.pdok.nl:443 "GET /kadaster/adressen/wms/v1_0?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities HTTP/1.1" 200 9391
2026-06-26 19:21:18,257 - GeoHealthCheck.probe - INFO - response: status=200
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.HttpStatusNoError result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.XmlParse result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.NotContainsOwsException result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.ContainsStrings result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Result: success=True msg=OK response_time=0.103404
2026-06-26 19:21:18,262 - scheduler - INFO - 1 run_resource OK
Describe the bug
The APScheduler suddenly gives errors.
To Reproduce
Steps to reproduce the behavior, e.g.:
Expected Behavior
No error.
Screenshots or Logfiles
Context (please complete the following information):
If running with Docker:
**Analysis
I suspect this happens since
tzlocalupgrade to latest version related to APScheduler. The previous wastzlocal<3.0Now:
See YelpArchive/elastalert#2968
Plus seems to happen only on existing databases, i.e. jobs stored.
Suspect difference/mismatch between: "Offset-naive and Offset-aware datetimes".
Newly added jobs work ok, like this local instance: