-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with rule when DTSTART is set and "Z" Time Zone Identifier is apart of the datetime string. #106
Comments
The lib currently does not support parsing TZID from DTSTART. Your problem stems from a bug in the rule loader where the instantiated DTSTART, DTEND, and UNTIL DateTimes aren't adjusted to your desired timezone when they contained the UTC designator (or any timezone identifier recognized by \DateTime's parser). I'm debating the best way to handle this problem. A couple options floating around in my head:
Given a PHP timezone of America/Denver, and using your example:
I'd like to remove timezone conversion from the library entirely, leaving it up to the user, but I think that's going to be a "2.0" thing. DATE-TIME values without a TZID or UTC designator are supposed to be floating dates (e.g. A person is unavailable from 11am - 3pm no matter what timezone he/she is in.) So, instead of doing any timezone conversion on DTSTART, a recurrence would include a |
@simshaun thank you for the response. I suppose my expectation was that the RRule would be the ultimate determining factor in start date time and timezone according to the DTSTART. I ultimately was confused on how best to setup the rule constructor. In your first option "Remove support for DTSTART and DTEND in the RRULE string since they aren't actually part of a real RRULE string" I am confused because to my understanding DTSTART and DTEND are apart of the rule iCalendar spec. (https://www.ietf.org/rfc/rfc2445.txt [page 30]) I may have misunderstood you. Thinking through this I think the best option would be to rely on the RRule to specify the start date and timezone. This way the user can ultimately determine if they need it floating or precise and the RRule becomes the reference point, which I would think would be fitting if we would stick to the standard. For the mean time I think option two would be the best bet to fix the bug. |
They're part of an iCal object, but not part an actual RRULE string. See the example at the bottom of page 53, https://tools.ietf.org/html/rfc2445#page-54. I plan on handling this differently with #94. My goal is to accept an actual iCal object, extract the VEVENTS, and generate occurrences from there. DTSTART and DTEND in each VEVENT would be the source of truth, so there will be no Anyway, I've got the bugfix for this ready and will release it tonight when I get home. |
That sounds like a great way forward. Thank you for the quick bugfix! |
My RRule is:
FREQ=WEEKLY;DTSTART=20161130T013000Z;DTEND=20161130T030000Z;BYDAY=TU;UNTIL=20170124T140000Z;WKST=MO
If I am in Mountain Time the start date is actually 11/29/2016 6:30 PM. So I would expect the first recurrence item start to be:
However this is what is returned:
The first issue is the occurance didn't include the start date as the first occurrence. Second I would expect that occurrence to be:
In my rule declaration I have tried setting the Timezone attribute to both Mountain and UTC with the same results. If I declare a start date it gets overridden by the DTSTART (I don't know if this is intentional). Is this a lack of logic to handle the DTSTART attribute with a Time Zone Identifier? According to the calendar spec having a Time Zone Identifier is accepted. It appears that even though the start date is in UTC it converts it again during recurrence generation.
The text was updated successfully, but these errors were encountered: