Affects: All versions, tested with 4.3.10 and verified to still be a problem in tip of master ec97089
It seems that Spring task scheduler implementation still uses old java.util.Date for some of its timings (esp. tasks delayed by time) and it is not possible to easily inject a different clock source, such as java.time.Clock bean instance or via SchedulerConfigurer.
Such a feature would be very valuable for unit testing time-dependent functionality, which now requires use of PowerMock or JMockit to directly patch System.currentTimeMillis, Clock.systemUTC or both.
So you'd like to specify a java.time.Clock bean through SchedulingConfigurer, expecting it to be picked up in the runtime scheduling setup wherever we're currently calling System.currentTimeMillis() for scheduling decisions? That seems feasible, and aligned with where Bean Validation 2.0 went with its ValidatorFactory.getClockProvider() method.
I'm not sure we need a system-wide Clock bean at the core context level since we're only really using timestamps for logging and monitoring elsewhere, not for time-based decisions, so I suppose we would still prefer the real clock for those purposes even in a test setup.
A related recent request for a configurable clock bean to be provided for test setups: #24884 - we'll try to revisit the topic for 5.3.
If you were specifying a custom Clock bean for scheduling purposes, what exactly would you expect it to be used for? All time taking, including monitoring and metrics such as actual execution time, or just time-based decisions such as trigger calculations? Would you try to used a fixed clock (always returning the same timestamp) or rather some kind of custom mutable clock?
I've added Clock exposure to TaskScheduler and TriggerContext, consistently used within our implementation instead of System.currentTimeMillis() and new Date() calls now, configurable via setClock calls on ThreadPoolTaskScheduler and ConcurrentTaskScheduler.
Most helpful comment
I've added
Clockexposure toTaskSchedulerandTriggerContext, consistently used within our implementation instead ofSystem.currentTimeMillis()andnew Date()calls now, configurable viasetClockcalls onThreadPoolTaskSchedulerandConcurrentTaskScheduler.