Existing scheduled jobs removed after upgrading APScheduler to 3.11.0 and switching from pytz to zoneinfo

[Saqibs575]

I recently upgraded APScheduler from version 3.9.1 to 3.11.0.
As part of this upgrade, I also migrated my project from using pytz to zoneinfo (as recommended for Python 3.9+).

However, I noticed that when loading my existing scheduled jobs from the job store, APScheduler was deleting all existing jobs. After checking the logs, I found that this happened because the old jobs were serialized with pytz timezones, and since pytz was no longer installed, the deserialization failed with a ModuleNotFoundError: No module named 'pytz'.

To prevent job deletion, I reinstalled pytz, and things started working again.
But I’m concerned that on other environments, these jobs might still be removed unexpectedly during upgrades or migrations — which is not ideal, since existing scheduled jobs should be preserved.

Do we have any parameter/setting that can help to avoid deletion of jobs (I have checked APScheduler code, but cannot see such parameter/setting)?

Steps to Reproduce:

• Use APScheduler 3.9.1 with a job store and schedule jobs using pytz timezones.

• Upgrade APScheduler to 3.11.0.

• Remove pytz and switch to zoneinfo.

• Start the scheduler and attempt to load existing jobs.

Expected Behavior:
Existing jobs should be preserved and loaded successfully (or at least skipped with a warning if timezone deserialization fails), rather than being deleted.

Actual Behavior:
Jobs are automatically removed from the job store because APScheduler encounters an error deserializing the timezone (ModuleNotFoundError: No module named 'pytz').

Workaround:
Reinstalling pytz prevents the deletion and allows old jobs to load correctly.

Environment:

APScheduler version: 3.11.0

Python version: 3.12.10

Timezone library: zoneinfo (previously pytz)

Job store: SQLAlchemyJobStore

[agronholm]

This is an unfortunate mechanic that has been removed in v4 (which is still in alpha). An obvious workaround would be to install pytz again to allow the deserialization to work. Perhaps there could be a mechanism in __setstate__() in the trigger classes that would automatically migrate from pytz to zoneinfo time zones, but I don't have the bandwidth to implement this at the moment.

[Saqibs575]

Thanks for your clarification, can you please provide the tentative release date of v4 (stable).

[agronholm]

I can't, really, as I'm randomly working on it whenever I feel like it.