The timezone flavor of get_occurrences() fails to find an icaltimezone, causing occurrences to be offset when transitioning in to/out of daylight savings time.

[groner]

If I'm not misunderstanding this, in order for libical to do the right thing it needs to have a timezone definition that includes daylight savings time.

Currently we're using the session timezone. This seems like a reasonable default, as long as the timezone name postgres has is known by libical. In a recurring calendar component, the timezone to use would be specified as a TZID parameter on the DTSTART property. PostgreSQL's timestamp with time zone type only stores the timezone offset, so we need to provide the TZID some other way.

@petropavel13 If this all makes sense to you, what do you think of adding variants of get_occurrences() that accept tzid as a parameter?

[groner]

Ok, it looks like it's a little more complicated than I thought. libical is trying to find a builtin timezone that matches the name and gmt offset pg_rrule is passing it. But the pg_get_timezone_offset() call we use is checking to see if the given timezone maps to more than one offset. If it does, then returns false without setting the offset.

[groner]

I attempted a patch that uses timestamp2tm() to get a struct pg_tm for the current time and timezone. This gets me a gmt offset and name, but unfortunately I have "EDT" and libical wants "EST/EDT".

I'm going to set this aside for now, but I'm open to suggestions if anyone has any ideas.

[petropavel13]

If this all makes sense to you, what do you think of adding variants of get_occurrences() that accept tzid as a parameter?

Yeah. Sounds great. Waiting for PR ;)

[naquad]

Hi.

I'm seeing this is an old issue but I still get the same error on +03:00 (Europe/Kiev) and my check of occurrence fails :(

Can I somehow mitigate the issue? Passing timestamps with time zones didn't help.

Thanks.