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.
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.