db-scheduler icon indicating copy to clipboard operation
db-scheduler copied to clipboard

Spring Boot: always-persist-timestamp-in-utc has no effect

Open GeorgEchterling opened this issue 9 months ago • 1 comments

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

  1. Use db-scheduler-spring-boot-starter
  2. Use MariaDB
  3. Set db-scheduler.always-persist-timestamp-in-utc=true
  4. 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

GeorgEchterling avatar May 15 '24 10:05 GeorgEchterling

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);

GeorgEchterling avatar May 15 '24 10:05 GeorgEchterling

🎉 This issue has been resolved in v14.0.1 (Release Notes)

kagkarlsson avatar Jun 05 '24 07:06 kagkarlsson