judovana When filing regression bugs, it is helpful to include the steps to reproduce, expected results, and actual results as described in the Issue Reporting documentation. As a courtesy, I have taken the liberty of providing this information below:

Steps to reproduce

1. Install Jenkins 2.321.
2. Install Schedule Build plugin 244.vce2a_2e926127.
3. Create a Freestyle job and schedule it 1 day in the future.
4. Go back to the dashboard.

Expected results

Note: These are the actual results when running with Jenkins 2.320.

Observe that on the right there are two icons: a blinking "Schedule a build for ${JOB_NAME}" clock and a non-blinking "Schedule a build" clock.

Actual results

Observe that you do not see a blinking "Schedule a build for ${JOB_NAME}" clock on the left anymore. Instead it is replaced with a non-blinking green arrow. The button on the right for "Schedule a build" remains a non-blinking clock as before. It is jarring that one icon would be replaced but not the other. And there is a loss of information because the left icon no longer blinks, thereby no longer distinguishing the in-queue state as reported.

Observation

Bisection shows this was caused by JENKINS-68229 in jenkinsci/jenkins#5851.

Hi! Deserved rebuke taken. thank you very much for looking into it even with such poor report.

While I can't offer much spare time to work on this issue at the moment, I'll drop a quick reply how the issue could be addressed nevertheless, incase someone else wants to pick it up:

From quick sca nit seems, that al the logic is already in jenkins, only identical icon is drawn, if the build is scheduled and in queue as if it is not in queue (not scheduled or running)

This statement fits well, the logic itself remained untouched in Basil's mentioned PR. Reintroducing the ternary that checks whether the job is queued up or not placing the icon-clock-anime gif restores the regressed behavior.
However, that would be the bad way, because the clock itself is no longer used in Jenkins itself to trigger a build and subject to removal in future versions of Jenkins in favor of more up to date icons.

The better approach (in my mind) would be to create a pulsing CSS animation of the play.svg or something similar that indicates the job is queued up. (See progress-animation.less for already existing CSS animations in Jenkins)
 

Hello!
Thanx a lot for insight!
The removal of clocks is expected seeing the svg icons, and I do not expect them be back. Still the logic that the icon will be different or animated if the build is already scheduled remains as valid. Also it is notable, that animated svg icons already have precedent in modern-style jenkins.

Thanx a lot all!

I opened a PR to have the previous behavior.

https://github.com/jenkinsci/jenkins/pull/6534