disagreement with crontab.guru

[jjb]

Because the readme links to crontab.guru i thought maybe it was worth making a ticket to explore a disagreement that rufus-scheduler / fugit have with it. Let me know if I should create this ticket with regit (or crontab guru) instead.

I was seeing 0/1 * * * * not behave as expected, and discovered I should use */1 * * * * instead.

This ticket discusses it: #284

For 0/15 * * * *

• rufus / fugit: in the range from the minute 0 to the minute 0, with a step of 15 minutes
• crontab.guru: At every 15th minute from 0 through 59

Is this due to one of them conflicting with mainstream cron implementations, or different mainstream cron implementations, or one of them being wrong, or something else? :-D

# These two work as expected
scheduler.every '1 minute' do
  puts "1 minute #{Time.now}"
end
scheduler.cron '*/1 * * * *' do
  puts "*/1:  #{Time.now}"
end

# does not raise exception, silently does nothing
scheduler.cron '0/1 * * * *' do
  puts "0/1:  #{Time.now}"
end
# Just to make sure some strings do raise exception
# yes, this breaks
# scheduler.cron 'broken * * * *' do
#   puts "broken?"
# end

[jmettraux]

Hello,

so I saw that

# does not raise exception, silently does nothing
scheduler.cron '0/1 * * * *' do
  puts "0/1:  #{Time.now}"
end

I interpret it as "nothing happens with "0/1 * * * *".

and rolled my own test:

require 'rufus-scheduler'

puts
puts "-" * 80
p [ :os, `uname -a`.strip ]
p [ :r, RUBY_VERSION, RUBY_PLATFORM ]
p [ :rsc, Rufus::Scheduler::VERSION ]
p [ :fugit, Fugit::VERSION ]
puts
EtOrbi._make_info
puts "-" * 80
puts

scheduler = Rufus::Scheduler.new

puts Time.now
puts Fugit::Cron.parse('0/15 * * * *').next_time.to_s
puts

scheduler.cron '0/15 * * * *' do
  p [ :CRON, Time.now ]
end

scheduler.join

Running it yielded:

--------------------------------------------------------------------------------
[:os, "OpenBSD yawara 6.8 GENERIC.MP#2 amd64"]
[:r, "2.6.6", "x86_64-openbsd6.7"]
[:rsc, "3.7.0"]
[:fugit, "1.4.0"]

(secs:1608326726.59701,utc~:"2020-12-18 21:25:26.5970098972320557",ltz~:"JST")
(etz:nil,tnz:"JST",tziv:"2.0.2",tzidv:nil,rv:"2.6.6",rp:"x86_64-openbsd6.7",win:false,rorv:nil,astz:nil,
eov:"1.2.4",eotnz:#<TZInfo::DataTimezone: Asia/Tokyo>,eotnfz:"+0900",eotlzn:"Asia/Tokyo",eotnfZ:"JST",
debian:nil,centos:nil,osx:"Asia/Tokyo")
--------------------------------------------------------------------------------

2020-12-19 06:25:26 +0900
2020-12-19 07:00:00 +0900

[:CRON, 2020-12-19 07:00:00 +0900]

So it does something, at least on my system.

Now I have tried that on my OpenBSD crond:

*/15 * * * * touch /var/nada.txt
0/15 * * * * touch /var/nada.txt

It rejects "0/15" as "bad minute". "*/15" works as expected.

"*/15 * * * *" does not do nothing and I stand by my answer in #284.

Best regards.

[jjb]

hah, sorry to lead you down a rabbit hole (although, education and entertaining)

so my "silently does nothing" really meant "i don't know what the semantic sare"

my main question here is this:

For 0/15 * * * *

• rufus / fugit: in the range from the minute 0 to the minute 0, with a step of 15 minutes
• crontab.guru: At every 15th minute from 0 through 59

Is this due to one of them conflicting with mainstream cron implementations, or implementing different mainstream cron implementations, or one of them being wrong, or something else? :-D

[jmettraux]

@jjb wrote:

Is this due to one of them conflicting with mainstream cron implementations, or implementing different mainstream cron implementations, or one of them being wrong, or something else? :-D

I cannot answer for crontab.guru.

I don't know what "mainstream cron implementation" means to you.

I built rufus-scheduler and fugit inspired by the documentation yielded by man 5 crontab, I work with MacOSX, Debian GNU/Linux and OpenBSD. There is also fourteen years of production use and conversation with users.

I do not know what the people at Crontab.guru are basing their implementation on. If it works for the crond they are using, then they are right.

But, if you look carefully at Crontab.guru, notice the warning they are emitting:

they say:

Non standard! May not work with every cron.

I have already written a lot in #284 and here.

I think my implementation and interpretations and cherry-picking of the various cron syntaxes out there is good enough. If you think it is wrong, then do not use rufus-scheduler or fugit.

[jjb]

Thanks for all the info! I wasn't challenging fugit's semantics of seeking a demonstration that its design is reasonable, sorry if it seemed that way. There are several implementations of cron and I was wondering if fugit aligned with one (seems you are saying yes, it aligns with vixie cron), crontab.guru aligns with another, or if one or the other is incorrect, in which case maybe we should let them know.