VTIMEZONE transitions in calendar feed generation

[j03k64]

Am I missing something or is there not support for having the calendar generation include VTIMEZONE entries for DST and Standard transitions?

I found this, but I wouldn't do it this way. I would just use RDATE entries per offset and transition.

Something like this:

BEGIN:VTIMEZONE
TZID:America/New_York
X-MICROSOFT-CDO-TZID:10
BEGIN:DAYLIGHT
DTSTART:20080309T070000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
RDATE:20090308T070000
RDATE:20100314T070000
RDATE:20110313T070000
RDATE:20120311T070000
RDATE:20130310T070000
RDATE:20140309T070000
RDATE:20150308T070000
RDATE:20160313T070000
RDATE:20170312T070000
RDATE:20180311T070000
RDATE:20190310T070000
RDATE:20200308T070000
RDATE:20210314T070000
RDATE:20220313T070000
RDATE:20230312T070000
RDATE:20240310T070000
RDATE:20250309T070000
RDATE:20260308T070000
RDATE:20270314T070000
RDATE:20280312T070000
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20081102T060000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
RDATE:20091101T060000
RDATE:20101107T060000
RDATE:20111106T060000
RDATE:20121104T060000
RDATE:20131103T060000
RDATE:20141102T060000
RDATE:20151101T060000
RDATE:20161106T060000
RDATE:20171105T060000
RDATE:20181104T060000
RDATE:20191103T060000
RDATE:20201101T060000
RDATE:20211107T060000
RDATE:20221106T060000
RDATE:20231105T060000
RDATE:20241103T060000
RDATE:20251102T060000
RDATE:20261101T060000
RDATE:20271107T060000
END:STANDARD
END:VTIMEZONE

And I was thinking of adding it to VCalendar object to add support for generating the VTIMEZONE entries based on the events in the calendar via a method call (something like generateTimezoneTransitions) that would be up to the user to call before the calendar's serialize method.

I also plan on adding the additional validation rules to VTIMEZONE class as well (based on https://www.kanzaki.com/docs/ical/vtimezone.html):

Thoughts/Concerns/Suggestions before I fork and implement this?

[evert]

Yea this never happened. Most implementation thankfully understand olson TZID's so it's never been a major problem.

It's not easy to do this though. I'm not a fan of the RDATE approach because it doesn't fully represent the underlying model. What would be really awesome is using RRULE instead.

Ideally we take the OLSON timezone database, pre-generate all the VTIMEZONE blocks and store them along with the project instead of generating them every time on the fly.

Full-disclosure: I don't have time to support this or help implement this. I basically moved on from this project for time constraints. There's new maintainers, so take this comment as a non-authoritative opinion from a random bystander, nothing more.

[j03k64]

Thanks for the quick response. I wasn't looking for support to help implement, just making sure I wasn't missing anything; along with looking for pointers on if you had specifics on what you were thinking if you were to implement it.

Yeah I'd love to do the RRULE implementation (since I saw it in that reference I mentioned), but figured it would be "harder" and pretty much already have the RDATE implemented (didn't find it that difficult, but I also haven't done a ton of testing to validate my implementation).

Interesting idea of storing the transitions with the project. I don't generate live (they run in an async worker and then are stored on s3), so the "cost" of doing those calculations wasn't noticeable.

[odolbeau]

It looks like this bug isn't fixed and the workaround isn't working anymore.

I'm not able to use add (it doesn't start a block).

$vtimezone->add('DAYLIGHT', [
  // ...
]);

And the createComponent method doesn't exist.

$vtimezone->createComponent('DAYLIGHT', [
  // ...
]);

May I help on this issue? (even if I don't really know how)

[renaudboyer]

$timezone->add('DAYLIGHT') won't work as DAYLIGHT is not declared as a component of VCalendar because $timezone->add() have to detect type and eventually use its $root which is a VCalendar to create component.

You can create generic component with createComponent function of the VCalendar containing the VTimezone and add it to the VTimezone.

A more elaborate way could be to create VDaylight and VStandard Component classes to handle them but it's more complicated.

[evert]

Adding those components is probably a nice first step. Although they should just be called Daylight and Standard

[cliffordp]

From https://tools.ietf.org/html/rfc2445#section-4.6.5

This is an example showing time zone information for the Eastern United States using "RDATE" property. Note that this is only suitable for a recurring event that starts on or later than April 6, 1997 at 03:00:00 EDT(i.e., the earliest effective transition date and time) and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid date and time for EST in this scenario). For example, this can be used for a recurring event that occurs every Friday, 8am-9:00 AM, starting June 1, 1997, ending December 31, 1997.... (emphasis added)