Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Cronexpr, a Rust library to parse and iter crontab expression

docs.rs

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#21

Post by vlovich123 »

tison wrote: post #4
cuu508 wrote: post #2

Looks well done. I like how the docs describe every syntax feature, and every non-standard feature in detail. Hat tip to implementing Vixie's "*,10" quirk, and to handling DST.

You're welcome! As described in the "Why do you create this crate?" section, I actually started this domain only a few weeks ago. So I experienced how those tribal rules can be confusing and hard to search over the Internet the understand their semantic. And when I sorted out the parse structure [1] and finished the extensions [2][3], I believe I should write it down for others (and future me) :D [1] https://github.c…

Is there a comparison to other cron parsing libraries like Saffron?

https://github.com/cloudflare/saffron

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#23

Post by epage »

tison wrote: post #19
epage wrote: post #18

After working with Jenkins which has "hashed value" support for automatic staggering of jobs, I think its essential in any cron syntax evaluater.

This can be optionally supported. To be clear, does it mean almost "RANDOM at construction" and the parser will assign a value by a hash/random function and then the crontab struct has an immutable value of that field?

The way jenkins did it is they took the job name and hashed that. This gives you good staggering while still being consistent from run to run (compared to using a random number). This does mean it is immutable, not just at construction but ideally across separate constructions so long as the seed is the same.

For an API, I could see either taking in something that is hashable or just taking in a number and letting the caller choose their hashing. From the person's perspective writing cron syntax, they shouldn't care so long as they get the intended affect.

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#25

Post by proaralyst »

1oooqooq wrote: post #24

isn't cron removed from most distros? now you need 3 or 4 different files for systemd-cronie

Systemd timer units are usually two: one for the service you want to run, one for the timer file.

I think you're confusing systemd timer units with Cronie[0], a crond implementation that I think predates systemd? It's possible there's some systemd thing I don't know about though!

I think most distros at least have an installable crond

[0]: https://github.com/cronie-crond/cronie/

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#26

Post by burntsushi »

aaomidi wrote: post #9
tison wrote: post #8

Earlier quoted context omitted.

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...

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!

> 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.

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#27

Post by aaomidi »

burntsushi wrote: post #26
aaomidi wrote: post #9

Earlier quoted context omitted.

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!

> 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.

Sure that’s an alternative too.

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#28

Post by Denvercoder9 »

tison wrote: post #8
Black616Angel wrote: post #3

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

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...

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).

Re: Show HN: Cronexpr, a Rust library to parse and iter crontab expression

#29

Post by franga2000 »

qwertox wrote: post #14

If you're into Python, APScheduler is the way to go. It also has a cron scheduler [0] which includes scheduling down to seconds and perfectly integrates with asyncio [1]. async def myfunc(): print(f"\n{Fore.GREEN}Readout triggered at { datetime.now().strftime('%H:%M:%S') }{COLORS_RESET}\n") await disk_temperatures_handler.readout(storage) scheduler = AsyncIOScheduler() storage['scheduler'] = scheduler scheduler.add_j…

+1 for APScheduler, we've been running it in production in multiple apps for going on 4 years now without any issue that I can remember.
Post reply on HN