top | item 41655596

(no title)

Black616Angel | 1 year ago

Main drawback is the need for timestamps. Most crontab files or expressions I've seen didn't have them.

discuss

order

tison|1 year ago

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|1 year ago

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.

Denvercoder9|1 year ago

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|1 year ago

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!

tison|1 year ago

Could you elaborate a bit on the issue? I'm not sure you are commenting on cronexpr or other libraries.

In cronexpr, there is no requirement for a timestamp until you'd like to find the next scheduled time, and thus you need to provide a related point.

To decouple with certain datetime lib, I made a `MakeTimestamp` struct which provides multiple constructors. Later, I found it somehow like a function overload :D

tricked|1 year ago

Do you mean timezones? if so it shouldn't be that hard to detect if there's no timezone and add it with your own code.

assiniboine|1 year ago

It doesn't need timestamps. It parses crontab to/from timestamps where needed.