Hacker News Reader

Comment by kccqzy | Hacker News Reader

I think this just speaks to a design wart in the seemingly simple crontab specification. I'm personally more of a fan of iCal-style (RFC5545) recurrence specification. Just check out the examples in https://www.rfc-editor.org/rfc/rfc5545#section-3.8.5.3

Here are some thing that's possible:

    Weekly on Tuesday and Thursday for five weeks
    Every other week on Monday, Wednesday, and Friday until December 24, 1997, starting on Monday, September 1, 1997
    Every other month on the first and last Sunday of the month for 10 occurrences
    Every 18 months on the 10th thru 15th of the month

(Almost all of those are well supported by the UI on Apple Calendar and Google Calendar.)

I only wish it could incorporate astronomical phenomena such as phases of the moon into account. Wouldn't it be great if it can express concepts like "the first Sunday after the full moon that occurs on or after the spring equinox" (no I'm not making this example up)?

View on HN

There is a trend towards turing-complete configuration languages, so why not. Of course there might be a race condition if the computation takes longer than the remaining time to the computed date.

This is so easy, just interpret a few hundred words :)

https://en.m.wikipedia.org/wiki/Date_of_Easter

… and you would still be wrong, depending in which country it gets calculated.

The things that are possible that are specified in the the parent is not how you actually write them fyi

> I only wish it could incorporate astronomical phenomena such as phases of the moon into account

You probably could hack something up around rfc 7529 (non-gregorian recurrence)

Phases of the moon are still important if you live near a body of water with strong tides. They also used to be important as a source of light.

At that point you might as well put a code interpreter in your scheduler that just gets current date and returns next data of event, because whole code to cover that would take more code than cron itself.

Teach GPT-3 cron syntax, done.

"What do you mean we need some NVIDIA cards to run our job scheduler ?"

I guess you can just say "Easter 2023"

Orthodox or Catholic?

gauß doesn't care, the changes are minimal.

The idea is not to hard code the computation of specific holidays, but to make the specification flexible enough.

Once dates get too complex it is easier to just have an external script figure out whether today is the day and have it run every day:

  0 9 * * * anvandare is-today-the-day.py && celebrate.sh

With is-today-the-day.py being:

  #!/usr/bin/env python3
  import sys
  from dateutil.easter import easter
  from datetime import datetime as dt
  today = dt.today().date()
  (easter(2023) - today).days == 0 and sys.exit(0) or sys.exit(1)

Or, if we didn't have the easter function already (just adding this because it was fun to work it out):

  #!/usr/bin/env python3
  import sys, ephem as e, datetime as dt
  setup = '2022/09/25'
  date = (e.next_full_moon(e.next_equinox(setup))).datetime()
  easter2023 = (date + dt.timedelta(7 - date.isoweekday())).date()
  today = dt.datetime.today().date()
  (easter2023 - today).days == 0 and sys.exit(0) or sys.exit(1)

No one said it was 2023

I wrote an RFC5545 parser and event generator once. No thanks.

So you saved all your library users the work needed for a powerful event generator system, what's wrong with that?

That was 1/3 of the problem domain of scheduling things. The other 2/3 was made considerably more difficult by it.

Reply on news.ycombinator.com