u01jmg3
commented
2 years ago @s0600204: again I understand if you're busy but your input would be welcome on this issue too
Closed arwinvdv closed 2 years ago
u01jmg3
commented
2 years ago @s0600204: again I understand if you're busy but your input would be welcome on this issue too
s0600204
commented
2 years ago dtstart_tz and dtend_tz represent the start and end points of an event local to the "timezone of the calendar". This, of course, requires some determination of what the "timezone of the calendar" is.
To do this, the ics-parser reads from the (non-standard) X-WR-TIMEZONE stanza, which in the ics sample given has a value of UTC. Remove this line and the ics-parser uses the last-specified VTIMEZONE instead (Europe/Amsterdam).
Personally, I advise not using dtstart_tz or dtend_tz - if you aren't in the same timezone as the one specified by X-WR-TIMEZONE, then neither are of any use.
If you wish to know the start of an event as a date-time local to a timezone of your choosing:
// Get the UTC timestamp of the date:
$start_utc = $event->dtstart_array[2];
// Create a php DateTime object:
$start_datetime = new DateTime('@' . $start_utc);
// Cast into the timezone you wish the output to be:
// (php-recognised timezones only: https://www.php.net/manual/en/timezones.php)
$start_datetime->setTimezone(new DateTimeZone('Europe/Oslo'));
// Output into a format of your choosing:
echo $start_datetime->format('Y-m-d H:i:s');As an aside:
RFC5545 doesn't specify a way to declare a "calendar timezone" or a "default" timezone - it doesn't need one: date-times specified without timezones are considered to be local to whatever timezone is "observing" (e.g. whichever timezone the reader is in). This does however mean that DTSTART=20210202T090000 when read by someone in Berlin refers to a different absolute point in time than when read by someone in New York (08:00 UTC and 14:00 UTC respectively).
To get round this, Google (and Apple and others) use the non-standard X-WR-TIMEZONE stanza to say: "All those floating date-times without an explicit timezone? They're all local to this one." (In case this is unclear: this runs contrary to the RFC5545 specification, and thus is - by definition - incorrect behaviour.)
(The standards-compliant way would be to not use floating date-times, but to explicitly specify a timezone for each and every one.)
The popularity of the non-standard stanza does present some interoperability problems: if we completely ignored it, we would get complaints about incorrect event times from users of Google Calendar/Apple iCal living outside the timezone specified by the stanza in question.
In reference to this particular issue however: we are presented with a date-time with an explicit timezone (UTC), so the "calendar's timezone" (such as it may or may not be) is irrelevant.
See also: https://blog.jonudell.net/2011/10/17/x-wr-timezone-considered-harmful/
u01jmg3
commented
2 years ago @s0600204: thank you for the detailed explanation
@arwinvdv: I'm closing this issue in light of the above. I would also recommend reading the attached article - even 11 years on it is still relevant.
7.2.21Europe/Brussels2.1.14Description of the Issue:
Google Calendar provides
X-WR-TIMEZONEattributed and aVTIMEZONE. When theX-WR-TIMEZONEisset it ignores theVTIMEZONE. But with the iCal I get from Google the events are one hour to early.The ics file:
Actual result:
Expected result:
Possible solution
In
calendarTimeZone($ignoreUtc = false)first check forVTIMEZONE?