[tison]

If you mean timezone, I wrote an FAQ [1]: "Why does the crate require the timezone to be specified in the crontab expression?"

[1] https://docs.rs/cronexpr/latest/cronexpr/#why-does-the-crate...

[qwertox]

Is `timezone` optional? I like it that it has the ability for one to provide it, but not providing it could just use the one the system has been configured to use.

[tison]

Yeah. Actually, this is possible to extend the interface with options to accept

1. Optional Timezone.

2. Second-level precision (perhaps feature flags are more suitable here)

It just falls out my first requirements so I don't support it. Being too generic is a common source of failure in my experience.

As a library developer I have my opinion on how things should be done and provide the default fits that mind :D

[Denvercoder9]

Requiring a timezone seems sensible to me, but I don't understand the choice to make it a required part of the expression, instead of a separate parameter. Most software specifies the timezone separately from the expression (e.g. k8s has separate `schedule` and `timezone` keys).

[aaomidi]

So many of these restrictions feels arbitrary. Not supporting comments? Why?

Assuming UTC for tz is not weird and cron users expect it,

I guess why even support this specific syntax if the crons need to be edited to fit how this code expects them? There may have been better options if you were going full green field.

Good work though!

[burntsushi]

> Assuming UTC for tz is not weird and cron users expect it,

That would definitely be weird and unexpected. My crons are interpreted with respect to my system's configured time zone, which seems way more expected than just using UTC.

Taking a datetime and just assuming it's UTC is often a mistake. It's why the TC39 Temporal proposal (overhauling datetimes for Javascript) won't let you silently do it.

[aaomidi]

Sure that’s an alternative too.