Comments (2)
Thanks for your reply, @rlanvin.
For context, Google calendar API seems to occasionally provide only a date value for UNTIL
for recurring events that start at a specific time (the example I posted above came directly from Google). Although not explicitly provided, the DTSTART
value in this case is 2023-01-05 07:00:00Z
as defined by the event's start time.
Perhaps I'm misunderstanding something, or perhaps this is a bug on Google's side. For this situation though, it seems I'll need to modify the UNTIL
value to use a 00:00:00
datetime prior to instantiating the RRULE
class in order to avoid the exception. Since the library seems to already do this internally, that was what prompted me to ask the question.
Essentially your first scenario is what I was envisioning. I probably have a myopic view of the issue, but to me this seems like a reasonable solution. I def respect wanting to keep the behavior as tight to the RFC spec as possible though. Maybe triggering an E_USER_WARNING
instead in this case would be suitable since it's still possible to proceed.
In any case, thank you for taking the time to discuss.
from php-rrule.
First, thank you for your work on this library 🙏
You are welcome!
Would it be acceptable for the library to be a little more forgiving in this case and allow a UTC datetime to be used as the value for DTSTART?
This is a good question. You are correct, this behaviour comes from the RFC 5545 section 3.3.10 and in fact the error message is a copy/paste of the specification. In theory of course the library could be more forgiving, but in practice I'm not in favour of relaxing this behaviour, because this would lead to confusion and different results in some circumstances. For example, in your code snippet, you are giving a DTSTART with time component (i.e. a datetime). But your UNTIL doesn't have one (i.e. it's a date only). If the library were to accept this, this would create an ambiguity with 3 possible interpretation:
- should the time component of the UNTIL be 00:00:00 and DTSTART whatever it is?
- or should the time component of the UNTIL be assumed to be the same as the one for DTSTART?
- or should the time component of DTSTART be ignored altogether because you didn't pass one in the UNTIL?
Each scenario has issues:
- Scenario 1 will mean that there won't be an occurrence on the date of the UNTIL (because the rule will stop at midnight on that day, but the occurrence will be at whatever time was in DTSTART, so past the UNTIL date).
- Scenario 2 modifies the rule, so generating a string version from the object will actually lead to a different rule (one with a time component in UNTIL).
- Scenario 3 also modifies the rule, but this time DTSTART will be different
More importantly, there is no way to know what is the intent of the programmer and to decide which option to choose. That's why the RFC explicitly rejects this case. The human needs to be more precise, so that the computation can be accurate and reproducible between implementations.
As a workaround in your example, could you simply use date_create()->format('Y-m-d')
to truncate the unnecessary time component that you don't need?
I hope that makes sense.
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
- 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.