wtime_to_minutes should not add padding

[benclifford]

wtime_to_minutes does not accurately convert a specified time (such as "48:00:00") to a number of minutes (2880), but instead adds on an extra minute.

This has caused confusion in this situation:

slurm on a system with a 48h job time limit will take job submissions with:

 --time=48:00:00

but will not take job submissions submitted with a libsubmit walltime of "48:00:00" (as libsubmit requests 2880+1 minutes, which is slightly more than 48h).

This UI behaviour is confusing.

[annawoodard]

Agreed!

[yadudoc]

Yikes! This was set to ensure that a request is made for at least a minute. For many providers with changes that went into the last libsubmit alphas, the wtime_to_minutes output is not used, but the user provided walltime string is passed to the scheduler as is.

[annawoodard]

For many providers with changes that went into the last libsubmit alphas, the wtime_to_minutes output is not used, but the user provided walltime string is passed to the scheduler as is.

I think that's even more reason not to pad things, we want to try to keep things as consistent as possible. We can just add a check to make sure we don't make a request for 0 minutes instead of padding everything with a minute.