Comments (13)
Hi,
First: you're welcome. :)
Now I'm sorry but your code doesn't look like it's part of this library. There is no Recurrence
class. Do you have some custom code on top of the library that could cause this issue maybe?
from php-rrule.
Oups, i forgot the most important part...
Yes the Recurrence part is part of my code : https://github.com/BrunoSpy/epeires2/blob/test/module/Application/src/Application/Entity/Recurrence.php
But it does basically nothing else than wrapping your lib.
Without the recurrence class, it would look like
$rule = 'DTSTART;TZID=Etc/GMT:' . $this->getStartdate()->format('Ymd\THis') . '
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20160629';
$rrule = new RRule($rule);
$rset = new RSet();
$rset->addRule($rrule);
foreach....
from php-rrule.
Alright I see. The problem is that you don't define a time component for the UNTIL
part. So by default, it's be 00:00:00
. Therefore, your rule is "until 2016-06-29 00:00:00", and indeed the last occurrence "2016-06-29 10:00:00" is beyond this limit, so is not returned.
Be careful of another gotcha: you are explicitly using GMT timezone for DTSTART
, but you are not explicitly using a timezone for UNTIL
, therefore it'll take your default (PHP) timezone.
So you should write UNTIL=20160629T100000+0000
.
EDIT: Actually this is an invalid syntax, sorry about that. The correct syntax is: UNTIL=20160629T100000Z
Let me know if this work!
Personnally I would suggest working with DateTime object and array directly, as it's more precise. If you have any suggestions as to how the library should handle this differently, feel free to share.
from php-rrule.
Thx for your help.
If this is the expected behaviour in the RFC, I think we can close this issue and I will fix my code.
from php-rrule.
If this is the expected behaviour in the RFC
Well... I re-read the RFC just to be sure, and I have to say it's not strictly the expected behaviour. Here is the relevant part of the RFC:
The value of the UNTIL rule part MUST have the same
value type as the "DTSTART" property. Furthermore, if the
"DTSTART" property is specified as a date with local time, then
the UNTIL rule part MUST also be specified as a date with local
time. If the "DTSTART" property is specified as a date with UTC
time or a date with local time and time zone reference, then the
UNTIL rule part MUST be specified as a date with UTC time. In the
case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
rule part MUST always be specified as a date with UTC time. If
specified as a DATE-TIME value, then it MUST be specified in a UTC
time format.
According to this, two importants things:
- it's invalid to have rules with
UNTIL
part that has no time component whenDTSTART
has a time component. So to be strict the parser should reject them. - The
UNTIL
part must always be in UTC. As far as I understand it, there is no way to specify a timezone. In fact, the format I suggested you use (with the timezone) is explicitly forbidden if you want to follow the RFC strictly:
The form of date and time with UTC offset MUST NOT be used. For example, the following is not valid for a DATE-TIME value: 19980119T230000-0800 ;Invalid time format
So, maybe the RFC string parser should be more strict?
from php-rrule.
3.3.10
[...]
recur-rule-part = ( "FREQ" "=" freq )
( "UNTIL" "=" enddate )
[...]
enddate = date / date-timeThe value of the UNTIL rule part MUST have the same value type as the "DTSTART" property.
So : UNTIL can be just a date and IF it's a date-time, it must be in a UTC format.
BUT as my DTSTART is a date-time, UNTIL must be a date-time also.
Conclusion : I will get rid of the time in my DTSTART to comply to the RFC but if I do that, will your parser be compliant ?
from php-rrule.
After some tests :
DTSTART;TZID=Etc/GMT:20160624T100000
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20160628T100000
Does not return 20160628
DTSTART;TZID=Etc/GMT:20160624
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20160628
Does not return 20160628
DTSTART;TZID=Etc/GMT:20160624T100000
RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20160628T100000Z
Returns 20160628
from php-rrule.
So it seems your parser is right but could be stricter... Maybe just a warning in order to not introduce a backward compatibility break ?
from php-rrule.
Thank you for your tests!
Ok so as we discussed before, test 1 is technically invalid from a RFC point of view, as UNTIL
must be in UTC (test 1 is missing the "Z" indicator at the end). The parser instead interprets the date with the default PHP timezone, which is not the expected behaviour of the RFC, I agree. I guess the expected behaviour would be to throw an exception - or indeed maybe just a warning. The other option is to call this a "feature" of the lib and document it. :-)
I believe test 2 should indeed return 20160628
according to the RFC, and you definitely identified a bug there. This is due to the parser converting the date into a DateTime
at the default PHP's timezone. For for example, in my case the "20160628" becomes "2016-06-28 00:00:00 Europe/Helsinki" (which is my default timezone), which translates to "2016-06-27 22:00:00 GMT". I definitely need to look into this.
Test 3 is valid from a RFC point of view, and the lib works as expected - no problem there.
from php-rrule.
After pulling my hairs many hours on this problem, I realized that your test 2 is also not valid according to the RFC. You cannot use TZID
with a date only... So I think the cause of all the problems is a parser that is not strict enough.
@BrunoSpy I pushed a commit in master to make the parser throw InvalidArgumentException for invalid DTSTART/UNTIL formats. Could you test and give me your feedback?
from php-rrule.
I'll give a try next week but I think you chose the right solution.
from php-rrule.
Just looked at your commits and tested it : that's fine for me !
from php-rrule.
Thanks!
from php-rrule.
Related Issues (20)
- Humanreadable gets monthly wrong HOT 4
- addExRule not working for me HOT 4
- Drop support for PHP < 7.3 HOT 2
- Daylight Savings Time issue with PHP 8.1 HOT 13
- How to create Rrule for every day from X to Y? HOT 4
- How to use exdate with byhour? HOT 3
- Question: Performance optimization when calculating occurrences using multiple rules HOT 3
- exRule and addRule conflict HOT 3
- More forgiving DTSTART behavior when using only date for UNTIL HOT 2
- Nested exrules HOT 2
- occursAt sometimes failing HOT 2
- Problem with getOccurrencesAfter HOT 9
- Removing all dates that are inside a DatePeriod from Rset HOT 1
- bi-weekly occurance wrong HOT 3
- dtstart vs. Repeat Dates / Current Time Not Considered in Calculation HOT 5
- humanreadable not so much HOT 2
- Looking for a way to add DTEND HOT 1
- Exrul not working
- Add alias methods for better reading of code HOT 1
- Legacy Code - Can I 'require_once' instead of composer ? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from php-rrule.