Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the second pull request for issue #180. The first one added unit testing (PR #209), so that the fixes contained in this pull request can be automatically tested.
The pull request fixes four topics:
In iCalDateToUnixTimestamp it removes the $offset completely, as this is not only not needed, but simply wrong. With the $offset, the returned UNIX timestamp is incorrect. $forceTimeZone is already handled in iCalDateToDateTime, so there is no need to add an extra offset for it.
In processRecurrences it removes the $isAllDayEvent completely. It was previously used to set the timezone hard to UTC, but this has the unintended side effect of shifting whole day events by the timezone offset, if the initial timezone of the ICS data was not UTC. E.g. there is ICS data with a base timezone of Europe/Berlin and an event with start date 20180701, end date 20180702. It would then be treated as an all day event, but its resulting start datetime would be 20180701T000000 UTC which is wrong. Without the $isAllDayEvent, these all day events are now calculated correctly in the original timezone.
In processRecurrences it adds an if-clause to the MONTHLY case, as otherwise for non UTC timezones the event series would contain double start or end events (original start event + recurrence event, both for the same day). The reason is the way the monthly recurrences are calculated. The if-clause simply filters these cases out.
In processEventIcalDateTime it adds a recalculation of the UNIX timestamp in the updated
$event
, as typically this method is used to update the DateTime (array index 3), but the UNIX timestamp (array index 2) is not updated accordingly (leading to a mismatch between DateTime-String (with timezone) and UNIX timestamp.All changes can be tested with the unit testing (introduced with pull request #209). Simply run
composer test
.