Closed buffpojken closed 8 years ago
Yes, you're right, I agree this is a bug. Currently, :at
overrides the :starts
option so trying to set :starts
to something else isn't working as expected. The :at
option does imply a :starts
time when none is given but it should also take an existing :starts
option into account.
Thanks for prompt reply!
Hmm, yes - I see what you mean.
I'll see if I have time to PR that tonight or tomorrow.
What I think would be a more obvious behaviour is the following:
:at
should be used to set hour/minute in terms of when within a given day a given recurrence start but
:starts
should be used to set a starting date.
The combination of date + time within the scope of :starts
doesn't really make sense since the relevancy of the time-part is highly contextual on the other set of rules within a given recurrence context, and no expressiveness is lost by separating those into two separate options, i.e. {:starts => "2016-12-31", :at => "5 am"}
is equivalent with {:at => "2016-12-21 5 am"}
.
Basically, what I'm proposing is that :at
should ignore (and not set) any date parts while :starts
should ignore (and not set) any time parts provided.
Thoughts?
Hmm, follow-up thought:
Given the behaviour described above - :starts
as a term should maybe be renamed to :from
or similar?
Thanks for your ideas, I'd have to give this some thought. Treating :starts
as only the date parts could be plausible but I want to consider how this affects other use cases. This all touches on a semantics issue I noted in #6; :starts
is playing dual roles as either the actual starting point of the recurrence and, in other cases, just a lower bound, like a :from
or :after
option would suggest.
@buffpojken I opened #43 as a way to reconcile that :starts
acts like a date or a datetime depending on the context. Now when using :at
, the recurrence will start at the first :at
time of day on the date represented in the :starts
timestamp. Let me know what you think, otherwise, I'll merge in the next day or so.
I think it looks splendid :)
I'll test it out in our project once it's merged but it sure looks fine to me!
When using hash-notation to create a recurrence, starts doesn't seem to behave as expected, see attached example.
Shouldn't both the #merge and the new schedule with starts return dates after 2016-06-23?