Skip to content

CronSequenceGenerator.next() returns incorrect time [SPR-14480] #19049

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

Closed
spring-projects-issues opened this issue Jul 18, 2016 · 1 comment
Closed
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 18, 2016

Scott Albertine opened SPR-14480 and commented

I've found a cron line and timestamp pair that violates sane ordering of the CronSequenceGenerator#next(Date) function.

Demonstration test below:

	@Test
	public void demonstrateBug() {
		//I've found a cron line and timestamp pair that violates sane ordering of the CronSequenceGenerator#next(Date) function.
		long workingTimeStamp = 1468850400000L; //18 Jul 2016 14:00:00 GMT
		long problemTimeStamp = 1468867460443L; //18 Jul 2016 18:44:20.443 GMT


		String cronLine = "*/3 * 13 * * *"; //cron line that causes issues, found by fuzz testing
		CronSequenceGenerator generator = new CronSequenceGenerator(cronLine, TimeZone.getTimeZone("UTC")); //standard generator using that cron line
		Date correctNextRun = generator.next(new Date(workingTimeStamp));
		long correctNextRunTime = correctNextRun.getTime(); //correctly finds 1468933200000L
		//demonstrate that the problem timestamp is between the working timestamp and its next run
		Assert.assertTrue(workingTimeStamp < problemTimeStamp);
		Assert.assertTrue(problemTimeStamp < correctNextRunTime);
		//this means that, since the problem timestamp is between the working one and its next run, getting the next run of the problem timestamp should result in the SAME next run as the one from the working timestamp
		Date faultyNextRun = generator.next(new Date(problemTimeStamp));
		long faultyNextRunTime = faultyNextRun.getTime(); //incorrectly finds 1468933221000L
		Assert.assertEquals(correctNextRunTime, faultyNextRunTime); //THIS FAILS, demonstrating the bug.
	}

Affects: 4.3.1

Issue Links:

@spring-projects-issues spring-projects-issues added type: bug A general bug status: waiting-for-triage An issue we've not yet triaged or decided on and removed type: bug A general bug labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants