(non-blocking): Would it simplify the frontend code to alter the backend to support a full valid 5-value cron string?

Good question, hmm. Only if the backend was validating that we always received a full valid 5-value cron string (with optional timezone). The only reason it would help is so that I know I can pass these strings directly from the backend into JS cron libraries for validation and display.

Given that right now I have to first prepare them by using thisexpandScheduleCronString, which is a simple and well-tested function, I'm not overly concerned about it, but I do think a db migration for it that would have to expand stored values in the same way would be more complicated.

One situationI don't want is a user being able to set a 5-value cron string via CLI or API that sets day of month and month values. While the backend may ignore them, the FE would accidentally produce a confusing human-readable string for them like this:

At 09:30 on day-of-month 1 and on every day-of-week from Monday through Friday in February.

instead of

At 09:30 on Monday through Friday.

I plan on making the C/U form a set of widgets that under the hood produce a cron string. So imagine an input for time and another with the 7 days of the week that you select/deselect.

Conceptually, the form will look like:

time (TIMEZONE)[ 9:30                  c ]days[ ] Sun [x] Mon [x] Tues [x] Weds [x] Thurs [x] Fri [ ] SatYour workspace will auto-[start/stop] at 09:30 on Monday through Friday.

EDIT: Overall, my opinion is that the backend remains with the 3-value crontab as the cost is simply just this function we're looking at right now, which I think is acceptable. It doesn't seem like we fully bypass cost any which way unless the backend only supports 5-value cron strings and validates thatday-of-month andmonth are*.

Gotcha. Opened#993 for this; I can make the necessary frontend changes if needed.

I think the only changes that would be needed in a PR targeting#993 would be removing this function, which is ezpz 🎉

👍

nice