Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CronExpression fails to calculate properly next execution when running on the day of daylight saving time (March 27, 2022) #28245

Closed
mf81bln opened this issue Mar 29, 2022 · 5 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@mf81bln
Copy link

mf81bln commented Mar 29, 2022

In reference to #28095:

Affects: Spring Boot 2.6.4 / Framework 5.3.16 as well as newest versions Spring Boot 2.6.5 / Framework 5.3.17

We had an issue on DST switch on Sunday, March 27, 2022
We're using a simple TaskScheduler bean and a method annotated with @Scheduler(cron = "0 30 2 * * ?")

The execution was just skipped when time was jumping from 2am to 3am. I've tried to...

  • add the time zone to the taskScheduler
    @Bean
    public TaskScheduler taskScheduler(final TaskSchedulerBuilder taskSchedulerBuilder)
    {
        return taskSchedulerBuilder
            .poolSize(10)
            .customizers(taskScheduler -> taskScheduler.setClock(Clock.system(ZoneId.of("Europe/Zurich"))))
            .build();
    }
  • add zone property to @Scheduled
    @Scheduled(cron = "0 30 2 * * ?", zone = "Europe/Zurich")
    public void run() { ... }

Both didn't work - tried it by resetting system time to March 27, 2022 - 01:59:30am.

During debugging I found CronTrigger.nextExecutionTime() always returning 2022-03-28T02:30:00+02:00
Is there anything else I have to configure so that the execution is not just skipped? Or do I need a custom handling for this?

I've checked documentation as well as previous issues / fixes and couldn't find any specifics on how to properly handle this scenario where an execution falls into the "skipped" time frame between 2am ... 3am

I've also tried it with the newest versions Spring Boot 2.6.5 / Framework 5.3.17 (because this was fixed) and resetting the time of my machine to March 27, 01:59:30am - the execution was skipped again

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 29, 2022
@poutsma poutsma self-assigned this Mar 29, 2022
@mf81bln
Copy link
Author

mf81bln commented Mar 29, 2022

Addition:

cron under linux handles jobs falling in the skipped timeframe between 02:00:00am - 02:59:59am by running it immediately after the switch.

I'm looking either for a way to do/configure the same with a Scheduler (if it's not the default behaviour) or to configure how this should be handled, e.g. "run the job at 03:30:00+02:00".

@ropoman
Copy link

ropoman commented Mar 29, 2022

// Sunday at 4 am
@Scheduled(cron = "0 0 4 * * 0")
public boolean weeklyRun() {

I was surprised that my weekly cleanup run was not called. spring-boot-starter-parent 2.4.2

@poutsma
Copy link
Contributor

poutsma commented Mar 30, 2022

@milios On 5.3.17, that test runs fine. There have many CronExpression fixes since 5.3.12, specifically #28038 comes to mind.

@poutsma
Copy link
Contributor

poutsma commented Apr 4, 2022

I'm looking either for a way to do/configure the same with a Scheduler (if it's not the default behaviour) or to configure how this should be handled, e.g. "run the job at 03:30:00+02:00".

Scheduling the job at 2:30 AM will mean that your job will be skipped when transitioning to DST, because from the scheduler's perspective that time does not exist. The scheduler does not keep track of skipped jobs (as Linux' Vixie cron does), and there is no way to change that behavior. The only way is to change the schedule not to run during between 2AM and 3AM.

@poutsma poutsma closed this as completed Apr 4, 2022
@poutsma poutsma added status: declined A suggestion or change that we don't feel we should currently apply in: core Issues in core modules (aop, beans, core, context, expression) and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Apr 4, 2022
@mf81bln
Copy link
Author

mf81bln commented Apr 6, 2022

@poutsma Thanks for the feedback 👍
In this case I'll implement a workaround by extending CronTrigger and overriding CronTrigger#nextExecutionTime

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

4 participants