When setting the calendar timezone, conversions from the event time to the calendar time occur from UTC, completely ignoring the calendar default timezone. This not only yields a counterintuitive result, but also an incorrect one.
For example, a DTSTART of TZID=America/New_York:20181204T180000 will get converted to a dtstart_tz of 20181204T130000 when the calendar default is set to Europe/Copenhagen. Instead of being converted to UTC or Europe/Copenhagen (+5 or +6hrs after America/New_York at time of writing), the dtstart_tz gets converted to something that's -5 hours from America/New_York.
It should be added, that the unix timestamp parsed as element 2 of dtstart_array is correct.
It seems like this is down to the following code, inside iCalDateWithTimeZone:
if ($key === 'DURATION') {
$duration = end($dateArray);
$dateTime = $this->parseDuration($event['DTSTART'], $duration, null);
} else {
$dateTime = new \DateTime($dateArray[1], new \DateTimeZone(self::TIME_ZONE_UTC));
$dateTime->setTimezone(new \DateTimeZone($this->calendarTimeZone()));
}
// Force time zone
if (isset($dateArray[0]['TZID'])) {
if ($this->isValidIanaTimeZoneId($dateArray[0]['TZID'])) {
$dateTime->setTimezone(new \DateTimeZone($dateArray[0]['TZID']));
} elseif ($this->isValidCldrTimeZoneId($dateArray[0]['TZID'])) {
$dateTime->setTimezone(new \DateTimeZone($this->isValidCldrTimeZoneId($dateArray[0]['TZID'], true)));
} else {
$dateTime->setTimezone(new \DateTimeZone($this->defaultTimeZone));
}
}
This parses the value of $dateArray[1], which in this case, is 20181204T190000 for DTSTART, as UTC. It then sets the timezone with the calendar time zone, and finally with the "forced" timezone information found in $dateArray[0], which in this case is America/New_York.
The error, as far as I can tell, is that instead of parsing the time as America/New_York to start, it parses as UTC, then tries to set it to the event timezone of America/New_York.
I'm not familiar enough with this library to know if changing the behaviour in this function will produce side effects, so I've simply documented my findings here.
7.2.10
N/A
2.1.7
Description of the Issue:
When setting the calendar timezone, conversions from the event time to the calendar time occur from UTC, completely ignoring the calendar default timezone. This not only yields a counterintuitive result, but also an incorrect one.
For example, a
DTSTART
ofTZID=America/New_York:20181204T180000
will get converted to adtstart_tz
of20181204T130000
when the calendar default is set to Europe/Copenhagen. Instead of being converted toUTC
orEurope/Copenhagen
(+5 or +6hrs afterAmerica/New_York
at time of writing), thedtstart_tz
gets converted to something that's -5 hours fromAmerica/New_York
.It should be added, that the unix timestamp parsed as element
2
ofdtstart_array
is correct.Steps to Reproduce:
Example iCalendar (https://dl.tyzoid.com/test.ics):
Example Code:
This yields the following (snippet)
Code Exploration
It seems like this is down to the following code, inside
iCalDateWithTimeZone
:This parses the value of
$dateArray[1]
, which in this case, is20181204T190000
forDTSTART
, asUTC
. It then sets the timezone with the calendar time zone, and finally with the "forced" timezone information found in$dateArray[0]
, which in this case isAmerica/New_York
.The error, as far as I can tell, is that instead of parsing the time as
America/New_York
to start, it parses asUTC
, then tries to set it to the event timezone ofAmerica/New_York
.I'm not familiar enough with this library to know if changing the behaviour in this function will produce side effects, so I've simply documented my findings here.