CLI does not understand that day time follows night time

[Peter-Darton-i2]

TL;DR: I just wanted an overnight backup, but Error: period begintime 22:30 can not be later than endtime 07:00

UseCase

It all started with a simple enough requirement; run an overnight backup, overnight. As run it during the night time when all the pesky data-generating users were asleep.
Simple, I thought. Have an EC2 instance do the backup on bootup, then have it wake up on a schedule. My users are typically all asleep by 10:30pm. How hard can it be? 😇

In a world where daytime inevitably follows night time, this is simple.
Sadly, the AWS instance scheduler-cli had other ideas.

The problem

If you do scheduler-cli create-period --stack my-scheduler-stack --name nightly --begintime 22:30 --endtime 07:00 then you are greeted with a confidently-incorrect error message declaring:

Error: period begintime 22:30 can not be later than endtime 07:00

I'm not sure exactly what environment the scheduler-cli was written in but, where I live, if you start a 510 minute (i.e. 8.5 hour) timer at 10:30pm and wait until that timer expires, you'll find that it's now exactly 7am (if you want to test this yourself, you'll either need a very loud timer-expiry alarm or a lot of coffee to stay awake).
i.e. 7am 🌞 is exactly 8.5 hours later than 10:30pm 🌙.
(unless daylight savings happens/unhappens, but lets stick to GMT+0 for simplicity)

There is, of course, a 7am that is/was earlier than our 10:30pm start time too, but we cannot deny that there's also one that's later; such is the nature of the way we measure time. When one day comes to an end, another day starts.
It has done this with unerring regularity throughout my lifetime and there's no evidence to suggest that it's going to stop doing so any time soon. There's certainly insufficient evidence to suggest it won't continue to warrant having the scheduler-cli emit an error message confidently declaring that there will be no 7am following a 10:30pm start when all evidence indicates that this is untrue (and, if I am ever proven incorrect about this, I suspect that the lack of error message will be the least of our problems).

The proposal

It should "just work".
If a user says "start at 10:30pm mon-fri and end at 7am" then that 7am is obviously referring to the 7am that's 510 minutes after the start time.
By all means ask "Are you sure? Did you mean the following morning?" but don't tell the user that "the end of time is upon us".

I've seen various workarounds posted that seem to revolve around the idea of putting adjacent periods together such that, every time the scheduler checks, it'll get the desired answer even if the source data is piecemeal, but "it shouldn't be that hard". Ultimately, the CLI is meant to make these things easier, not harder. So, if this is a limitation within the scheduler lambda code itself, lets have the CLI handle that and turn a 10:30pm-7am period into whatever data the lambda code needs to "just work".

If we're concerned about CLI ambiguity and we want to ensure we don't accidentally do what the user asked for instead of what they meant, maybe we could have a stop-duration as an alternative to a stop-time so we could say "start at 10:30pm and stop 8.5 hours later"? That way, it's unambiguous what the user is asking for.

Without this, users will tend to have everything start at midnight (to avoid this issue). That has serious consequences - it'll mean that AWS' data centres workload will spike at the same time, and demand spikes are bad for business (they're expensive to handle) as well as bad for the environment (constant power demands are handled more efficiently, less CO2 etc). It'd be much better to let users spread their usage out and start earlier.
It's not often when you can legitimately call code "toxic" but this incorrect error message is actually harming the planet (albeit indirectly). That's quite a motivation for considering this an important issue.

Y'all know it makes sense, as sure as day follows night 😉

[hearde]

Instance scheduler in general does not handle midnight very well. We would like to improve this in a way that does not require users to work around it. I don’t think having the CLI create multiple periods in the background is the right fix since you then need to know this in order to configure your schedule correctly. The actual issue is that periods cannot cross midnight.

I am curious what your use case is that requires use of the CLI. The CFN custom resource allows you to declare your infrastructure as code, so that is what I would recommend using.

[Peter-Darton-i2]

Yup, I agree that it "does not handle midnight very well".
...and I would also agree that improvements that "just work" rather than workaround the issue would be better. IMO anything that addresses the "fundamental" issue would be preferable ... but I'd guess that the reason the issue is unsolved is because it's hard to fix the "fundamental" issue.
It might be more practicable to add support to the CLI to work around the issue in order to mitigate the problem until the root of the issue can be addressed.

I agree that using CFN is the best option in the long run ... but the documentation tells you to use the CLI, and using CFN more difficult such that even once a user has figured out how to use CFN for this, they'll likely need to interactively work out their desired configuration using the CLI before coding it in CFN.

In my case, I (eventually) found CFN examples and have since used that to give me config-as-code for my desired configuration.
I had previously been following the "normal" documentation for how to deploy and use the instance-scheduler and that documentation was consistently saying that the CLI was 100% necessary. So, when I failed to find any documentation/examples showing how to use CFN, I assumed that the earlier documentation was correct in its assertion that the CLI was necessary.
I now know that the documentation is wrong and the CLI is not necessary, and have switched to using CFN for that final configuration stage ... but I still used the CLI in order to figure out what CFN config I wanted.

TL;DR: Even if CFN is the end goal, the CLI is a useful intermediate step ... but I'd agree that being able to specify 10pm-5am in the CFN would be better.

[CrypticCabub]

Marking as an enhancement request to have the CFN schedule custom resource handle period wrapping automatically when defining periods that follow formats similar to begintime = 22:00, endtime = 4:00