Avoid legacy classes

You are using terrible date-time classes that were supplanted years ago by the modern java.time classes defined in JSR 310.

Keep servers in UTC

The default time zone (and locale) of your server should not impact your code. The settings there are out of your control as a programmer. So rather than rely on those defaults, always specify the desired/expected time zone (and locale) by passing optional argument to various methods.

Tip: Best practice is to generally keep your servers in UTC as their default time zone. Indeed, most of your business logic, logging, data exchange, and data storage should be done in UTC.

java.time

LocalTime

Each location has a target time-of-day.

LocalTime targetTimeOfDayParis = LocalTime.of( 9 , 0 ) ;  // 09:00.
LocalTime targetTimeOfDayNewYork = LocalTime.of( 9 , 0 ) ;  // 09:00.

Instant.now

Get the current moment in UTC.

Instant now = Instant.now() ;  // No need for time zone here. `Instant` is always in UTC, by definition.

ZoneId

When is that moment today? First define our time zones.

ZoneId zParis = ZoneId.of( "Europe/Paris" ) ;
ZoneId zNewYork = ZoneId.of( "America/New_York" ) ;

Instant::atZone

Then adjust from UTC in the Instant to the very same moment as seen through the wall-clock time employed by the people of a particular region (a time zone). That adjusted moment is represented by the ZonedDateTime class.

Note that this is not changing the moment. We have the same point on the timeline on both. Only the wall-clock time is different. Like two people on long-distance phone call can simultaneously look up at the clock on their respective wall and see a different time-of-day (and date!) at the very same moment.

ZonedDateTime zdtParis = now.atZone( zParis ) ;
ZonedDateTime zdtNewYork = now.atZone( zNewYork ) ;

ZonedDateTime::with

Change the time-of-day to our target. The ZonedDateTime::with method will generate a new ZonedDateTime object with values based on the original excepting for the values you pass. Here we pass a LocalTime to change from the hour & minute & second & fractional-second of the original.

The is the key part where we diverge for Paris versus New York. Nine in the morning in Paris is a very different moment than 9 AM in New York, several hours apart.

ZonedDateTime zdtParisTarget = zdtParis.with( targetTimeOfDayParis ) ;
ZonedDateTime zdtNewYorkTarget = zdtNewYork.with( targetTimeOfDayNewYork ) ;

Compare with isBefore

Did we miss 9 AM in either zone yet?

boolean pastParis = zdtParisTarget.isBefore( zdtParis ) ;
boolean pastNewYork = zdtNewYorkTarget.isBefore( zdtNewYork ) ;

If past, then add a day.

if( pastParis ) {
    zdtParisTarget = zdtParisTarget.plusDays( 1 ) ;
}

if( pastNewYork ) {
    zdtNewYorkTarget = zdtNewYorkTarget.plusDays( 1 ) ;
}

Duration

Calculate elapsed time using Duration class.

Duration durationParis = Duration.between( now , zdtParisTarget.toInstant() ) ;
Duration durationNewYork = Duration.between( now , zdtNewYorkTarget.toInstant() ) ;

Sanity-check that the durations are in the future, not the past.

if( durationParis.isNegative() ) { … handle error … } 
if( durationNewYork.isNegative() ) { … handle error … } 

Ditto for zero.

if( durationParis.isZero() ) { … handle error … } 
if( durationNewYork.isZero() ) { … handle error … } 

In real work, I would check to see if the duration is extremely tiny. If so brief that the code below may take longer than span of time, add some arbitrary amount of time. I'll leave that as an exercise for the reader.

Schedule work to be done

Prepare the work to be done.

Runnable runnableParis = () -> taskParis.work() ;
Runnable runnableNewYork = () -> taskNewYork.work() ;

Or you could write a utility that takes an ZoneId argument, looks up the work to be done, and returns a Runnable.

Schedule the work to be done. See the Oracle Tutorial on the Executor framework. This framework greatly simplifies scheduling work to be done on a background thread.

We schedule a task to be run after a certain number of minutes, seconds, or any such granularity has elapsed. We specify a number and a granularity with the TimeUnit enum. We can extract the number from our Duration calculated above.

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool( 1 );

ScheduledFuture<?> futureParis = scheduler.schedule( runnableParis , durationParis.toSeconds() , TimeUnit.SECONDS ) ;
ScheduledFuture<?> futureNewYork = scheduler.schedule( runnableNewYork , durationNewYork.toSeconds() , TimeUnit.SECONDS ) ;

The future object lets you check on progress status. You may not need it at all.

IMPORTANT: Be sure to gracefully shutdown your ScheduledExecutorService when no longer needed, such as when your app is ending.

Caveat: I have not tried any of this code. But it should get you headed into the right direction.

Note the repetition. There is no need to hard-code the city name in all those variables. You could write this logic once in a method that takes the ZoneId as an argument, and the time-of-day too if there is any chance it would vary by city. Then call that method for any number of zones.

List< ZoneId > zones = 
    List.of( 
            ZoneId.of( "Europe/Paris" ) , 
            ZoneId.of( "America/New_York" ) , 
            ZoneId.of( "Asia/Kolkata" ) 
    ) 
;
for( ZoneId z : zones ) {
    workManager.scheduleForZone( z ) ;
}