PR: Introduce pluggable TimeBroker as replacement for system clock

[ThanosTsiamis]

This PR addresses Provide TimeProvider #1372, which requested a way to replace Quartz’s hard-wired use of System.currentTimeMillis() with a pluggable, testable, and customizable time source.

Quartz previously had an SPI called TimeBroker, but it was deprecated and never wired through the scheduler. This PR revives and integrates that interface as the official mechanism for controlling Quartz’s notion of “current time.”

Important note: No change in default behavior

If no custom TimeBroker is provided, Quartz continues to use:

SimpleTimeBroker → new Date() → System.currentTimeMillis()

so backward compatibility is preserved.

Solves issue: #1372

Benefits

•	Enables deterministic time-control in unit & integration tests
•	Allows virtual clocks, offset clocks, or cluster-synchronized clocks
•	Fully backward compatible
•	No runtime or API breaking changes
•	Resurrects an existing SPI rather than introducing a new type

---

Checklist

• tested locally
• updated the docs
• added appropriate test
• signed-off on the DCO referenced in the CONTRIBUTING link below via git commit -s on my commits, and submit this code under terms of the Apache 2.0 license and assign copyright to the Quartz project owners
  (If you're not using command-line, you can use a browser extension )

---

In submitting this contribution, I agree to the terms of contributing as referred to here:
https://github.com/quartz-scheduler/contributing/blob/main/CONTRIBUTING.md

[ThanosTsiamis]

Hi there reviewers!
Please let me know if you have any comments on this (either on this PR or on the underlying issue).
It would solve a major obstacle on a multi service project that uses quartz and needs time travel

[ThanosTsiamis]

Hey maintainers! :) Any thoughts on this?
@jhouserizer @melloware

[ThanosTsiamis]

A few more words on the PR

In complex, distributed multi-service architectures, testing time-dependent logic is notoriously painful. Because Quartz has historically been hard-wired to System.currentTimeMillis(), simulating "time travel" or testing edge cases (like daylight saving shifts or specific execution gaps) requires altering the host system clock—which messes up everything else.

Deterministic Testing: A pluggable TimeBroker allows us to inject a frozen or fast-forwarded virtual clock during integration tests.

Cluster Synchronization: It gives teams the flexibility to hook into external time synchronization mechanisms if their environment demands it.

Backwards Compatibility Check

Looking through the implementation details and the files changed, this PR is incredibly safe and fully backwards compatible:

Zero Behavior Drift by Default: If the new property org.quartz.scheduler.timeBroker.class isn't specified, StdSchedulerFactory falls back to SimpleTimeBroker, which relies on standard system time.

Smart Asset Reuse: Instead of introducing a brand-new, breaking API type, this simply wires up and leverages the pre-existing TimeBroker SPI.

This is a massive quality-of-life win for modern testing setups with zero risk to legacy configurations.

@jhouserizer @melloware Let me know your thoughts =]

[ThanosTsiamis]

Greetings @melloware!
It has been ~300 days since the PR has been opened and no positive nor negative feedback has been made from any maintainer/developer!
Please, let me know your thoughts! =]

[melloware]

@ThanosTsiamis only @jhouserizer can merge PRs. I only have review privileges.

[ThanosTsiamis]

@ThanosTsiamis only @jhouserizer can merge PRs. I only have review privileges.

Thanks for clarifying, @melloware! 🙌 =]

Since the branch requires 2 approving reviews before it can be merged, a review or feedback from your side would still be immensely helpful in moving this forward.

Whenever you have a moment, I'd really appreciate your thoughts on the code changes! If you're unavailable, is there anyone else you'd suggest reaching out to alongside @jhouserizer?