```
val cronExp = "0 0 2 ? * *"
val Right(cron) = Cron(cronExp)
val Some(previous) = cron.prev(new DateTime())
val Some(previousPrevious) = cron.prev(previous)
This fail because last line return None... Any idea ?
can you run it in a REPL and paste the output here?
looks like a bug
let me do an additional check, it might be related with a known issue
so I can confirm this is due to a know bug: alonsodomin/cron4s#73
Joda has it’s part of guiltyness but the bogus behaviour is in the core
if you want you can add your case to that ticket as a comment, and I will make sure that there is a test case for it
sorry for landing into that nasty bug
val atBadDate = ZonedDateTime.parse("2017-06-30T23:30:45.123Z")
val Right(cron) = Cron("4 31 4 ? * *")
val next = cron.next(atBadDate)
But A value here:
val atGoodDate = ZonedDateTime.parse("2017-06-30T00:30:45.123Z")
val Right(cron) = Cron("4 31 4 ? * *")
val next = cron.next(atGoodDate)
*Note, both are on the same day of the month (the last day of June) but one is at start of day and the other closer to the end.
From my reading, the cron says: at 4:31:04, I don't care on what day of the month, every day of the week and every month.
by the looks of it, I think you are hitting issue #73
in your
atBadDate being earlier than midnight, the cron expression thinks it needs to advance the time from hour 23 to hour 4
which means that it needs to go pass midnight and therefore it brings a carry over factor of
1 towards the next date field, which is DayOfMonth
when applying such carry over to the current day of the month (
30) it tries to assing the day 31 to the month of June (6), which is an invalid date and fails returning a None
sorry for that, I was meant to have a fix ready a few weeks ago but I´ve been procastinating it a bit
I believe this is worth it’s own issue, would you mind creating one?
it would be good if you test it from master before I publish a new release.
val atBadDate = java.time.LocalDate.parse("2017-06-30")
val Right(cron) = Cron("4 31 4 ? * *")
val next = cron.next(atBadDate)
assert(next.nonEmpty)scala> val next = cron.datePart.next(atBadDate)
next: Option[java.time.LocalDate] = Some(2017-07-01)
or at least, it’s by design because the
LocalDate does not support updates in time fields
I think I would have assumed that for all date only fields (e.g. LocalDate) the user meant "at start of day". But I can see your point of view as well, since that may be surprising... why allow arguments to next like LocalDate without a time component at all?
truth is that I would be interested in hearing what is the more sensible approach
whether a type error or make the expression return a
LocalDateTime from the LocalDate
in such a case, there is still a question of what type to return? from the sub expressions (time, date)
in my view, following a similar criteria, they should return
LocalTime and LocalDate...