You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 zoneif (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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: