thephpleague / period

PHP's time range API

Home Page:https://period.thephpleague.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

A period must contain at least its starting datepoint

KrisLamote opened this issue · comments

Hi - first of all thanks for the small but sweet package, will be useful for overlapping periods validation.

While going through the code I noticed that the constructor is accepting the same $startDate and $endDate, with a notable exception message 'the ending endpoint must be greater or equal to the starting endpoint'.

On the other hand the contains method expects the input $datetime to be: stricktly smaller than the endDate. This suggests to me that the ending endPoint is considered to be outside the period. This last bit doesn't seem to be in line with the check in the constructor?

This suggests to me that the ending endPoint is considered to be outside the period.

This is as expected and as described in the documentation.

While going through the code I noticed that the constructor is accepting the same $startDate and $endDate, with a notable exception message 'the ending endpoint must be greater or equal to the starting endpoint'.

Because you need to be able to represent 0 duration Period. I don't see the inconsistency maybe you coud give me a concrete example of inconsistency ?

Agreed, re-reading the documentation - that's clear, please close this

Conversely, the ending datepoint is excluded from the specified period.

I would consider the starting endPoint to always be inside the Period. If the starting endPoint and the ending endPoint are the same, then the starting endPoint is also outside the Period -- that last bit sounds a bit strange to me. Specifically if you rephrase it as follows: sometimes the starting endPoint is inside the Period, but usually (when the duration > 0) it's inside :)

I also understand that diff, abuts and intersect highly depend on this concept - so I will also adopt your point of view.

cheers & thanks

After thinking about it, I think you are indeed correct this is a bug, even a 0 duration Time range has at least a starting datepoint 👍 . I'll release a minor fix because the change does not affect other comparison methods.

the fix has been released