db-scheduler
db-scheduler copied to clipboard
Spring Boot: always-persist-timestamp-in-utc has no effect
Expected Behavior
Setting the Spring property db-scheduler.always-persist-timestamp-in-utc=true
should create an AutodetectJdbcCustomization
with persistTimestampInUTC = true
.
Current Behavior
Setting db-scheduler.always-persist-timestamp-in-utc=true
has no effect on the created AutodetectJdbcCustomization
. The JdbcCustomization
must be manually corrected via a DbSchedulerCustomizer
.
In the case of MariaDB, the "utc_warning" still gets logged. It is also impossible to prevent this warning (except by silencing the logs), since even overriding the JdbcCustomization
with a corrected version doesn't prevent the DbSchedulerAutoConfiguration
from temporarily creating the incorrect variant.
For bug reports
Steps to Reproduce the bug
- Use
db-scheduler-spring-boot-starter
- Use MariaDB
- Set
db-scheduler.always-persist-timestamp-in-utc=true
- The "utc_warning" will appear and the Scheduler will incorrectly not use UTC timestamps.
Context
- DB-Scheduler Version : 14.0.0
- Java Version : 21
- Spring Boot (check for Yes) : [x]
- Database and Version : MariaDB 10.11.5
Logs
2024-05-15T12:08:44.768+02:00 INFO 134292 --- [ restartedMain] c.g.k.s.b.a.DbSchedulerAutoConfiguration : Creating db-scheduler using tasks from Spring context: [RecurringTask name=alert-orphaned-files, onComplete=OnCompleteReschedule with CronSchedule pattern=0 0 5 10 * ?, cronStyle=SPRING53, zone=Europe/Berlin, RecurringTask name=alert-pending-exports, onComplete=OnCompleteReschedule with CronSchedule pattern=0 30 6 * * ?, cronStyle=SPRING53, zone=Europe/Berlin]
2024-05-15T12:08:44.774+02:00 INFO 134292 --- [ restartedMain] c.g.k.s.j.AutodetectJdbcCustomization : Detected database MariaDB.
2024-05-15T12:08:44.774+02:00 INFO 134292 --- [ restartedMain] c.g.k.s.j.AutodetectJdbcCustomization : Using MariaDB jdbc-overrides.
2024-05-15T12:08:44.774+02:00 WARN 134292 --- [ restartedMain] c.g.k.s.j.A.utc_warning : MariaDB-schema does not support persistent timezones. It is recommended to store time in UTC to avoid issues with for example DST. For first time users, use setting 'alwaysPersistTimestampInUtc' to achieve this. Users upgrading from a version prior to v14.0.0 can either silence this logger, or perform a controlled upgrade to UTC timestamps. All old instances of the scheduler must be stopped and timestamps migrated to UTC before starting again, using 'alwaysPersistTimestampInUtc=true'.
2024-05-15T12:09:03.291+02:00 INFO 134292 --- [ restartedMain] c.g.k.scheduler.SchedulerBuilder : Creating scheduler with configuration: threads=10, pollInterval=10s, heartbeat=300s enable-immediate-execution=false, table-name=scheduled_tasks, name=dev-scheduler
I think this is caused by this part of DbSchedulerAutoConfiguration
, which was added in #357:
// Use custom JdbcCustomizer if provided.
builder.jdbcCustomization(
customizer
.jdbcCustomization()
.orElse(new AutodetectJdbcCustomization(transactionalDataSource)));
The default AutodetectJdbcCustomization
is created without receiving the configured value of alwaysPersistTimestampInUTC
. This also prevents the correct default in SchedulerBuilder#build
from working, since the jdbcCustomization
is always set in the auto-configuration:
final JdbcCustomization jdbcCustomization =
ofNullable(this.jdbcCustomization)
.orElseGet(
() -> new AutodetectJdbcCustomization(dataSource, alwaysPersistTimestampInUTC));
I think this can be fixed by simply removing the default jdbcCustomization
in DbSchedulerAutoConfiguration
. I.e.:
// Use custom JdbcCustomizer if provided.
customizer.jdbcCustomization().ifPresent(builder::jdbcCustomization);
🎉 This issue has been resolved in v14.0.1
(Release Notes)