[BUG] "quads-cli --date <future date> --host <hostname>" not calculating location correctly

[kambiz-aghaiepour]

• QUADS version (rpm -qa | grep quads and/or quads-cli --version): QUADS version 1.1.5 gaúcho
• Python version: Python 3.7.4
• Operating System: fedora-release-29-7.noarch

Describe the bug If a give host has a future schedule, and you want to see what the allocation of a host is for a given future date, it seems to only report the "current" location. I'm assuming this is due to the current code only looking backwards in time, and not currently able to look in the future?

To Reproduce

Here is sample output of how this is incorrect (assume the current active schedule is 6, and the current date is prior to the start of schedule 7 in this example; as of the time this issue is reported, the current date is 2022-01-13):

# date
Thu Jan 13 14:54:56 UTC 2022

# quads-cli --host myhost.example.com --ls-schedule
Default cloud: cloud01
Current cloud: cloud18
Current schedule: 6
1| start=2020-04-22 16:45, end=2020-04-23 15:00, cloud=cloud11
2| start=2020-04-23 15:00, end=2020-07-12 22:00, cloud=cloud30
3| start=2020-07-12 22:00, end=2020-07-26 22:00, cloud=cloud12
4| start=2020-08-02 22:00, end=2020-08-30 22:00, cloud=cloud14
5| start=2020-08-31 20:45, end=2021-10-21 18:00, cloud=cloud14
6| start=2021-10-21 18:00, end=2022-01-16 22:00, cloud=cloud18
7| start=2022-01-16 22:00, end=2022-01-30 22:00, cloud=cloud14

# quads-cli --host myhost.example.com
cloud18

# quads-cli --host myhost.example.com  --date '2022-01-17 22:00'
cloud14

# quads-cli --host myhost.example.com  --date '2022-01-31 22:00'
cloud18

As you can see in the above schedule, the current location is cloud18. And when you pass the --date argument for a date/time that falls during the next reservation (schedule 7 for this host) the correct result is given (cloud14). However, when you pass the --date argument and give a date that is beyond the last reservation as seen in schedule 7 above, the expected result should have been cloud01 but instead the current location which is cloud18 is reported again. This is misleading. There may be reason to want to verify that a host is returning to cloud01 beyond a specific date but the erroneous output can create unnecessary confusion.

Expected behavior Accurate output is expected.