timezone problems

Hi,
There is no “GMT+01.00/+02.00” in “the” tz database
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
The ics RFC5545 spec ‘suggests’ that the tz database be used:
https://tools.ietf.org/search/rfc5545#section-3.2.19
Php also does not have such a timezone – it uses the tz database too
https://php.net/manual/en/timezones.php

Some applications just do their own thing and it would appear that your first ics file is one of those. Over the years the plugin has coped with some of these oddities. EG: it will map the windows non-localised timezones, and If cities are listed, it will ‘guess’ the correct timezone.

It appears the plugin is treating it as GMT+1 (no daylight saving) and thus there would be some differences with Europe/Berlin because it does have daylight saving.

Which application is generating the GMT TZID?
Do you have control over the timezone ? Can you change it to something safer like a city based timezone?

The application may generate a timezone definition in the ICS file at the top. The plugin does not attempt to create a custom timezone from this (yet) – instead it attempts to map any strange TZID’s to the best matching php timezone.

The problem with a GMT based daylight saving change is that countries in the same longitude may NOT change DST at the same time, so what should the plugin do if it did try map it? which city based timezone would it use to get the right DST changes?

EG – these are both GMT+1 at some stage:
Germany: Sunday, 27 March Sunday, 30 October
Namibia: Sunday, 4 September Sunday, 3 April

More info:
https://icalevents.com/2613-what-every-developer-ought-to-know-about-timezones-wrt-calendar-files/
https://www.timeanddate.com/time/map/
https://www.timeanddate.com/time/dst/2016.html
https://www.webexhibits.org/daylightsaving/g.html

If you don’t have control over the originating system and do have some programming skills, there is a filter ‘amr-timezoneid-filter’ that is used to do the windows mapping. You could force map the TZID?

Or pre-process the ics file, changing the TZID ?
hope that helps

Hi,

the application which is creating these timezones is… Android… we have several entries made by several android devices and no common details (different apps used, different models and versions). All sync to a Zimbra server, some by Activesync, some by CalDAV.

Ah, yes, there is information in the header, and it looks the same than the following Europe/Berlin, only one detail at the DST start is different, the BYDAY is -1SU vs. 4SU which is the same in most marchs I hope ??

As we can’t change Android being used, I try your other solutions, thanx!

BEGIN:VTIMEZONE
TZID:GMT+01.00/+02.00
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETTO:+0100
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=10;BYDAY=-1SU;WKST=MO
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=4SU;WKST=MO
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETTO:+0100
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE

Greetings, Joerg

Hi,

btw: It seems only Zimbra does not realise these strange TZID strings. Google Calendar changes them to standard IDs so the problem does not occur.

But thanx to your hint, now it works, even with the cheap solution as all our TZIDs are local ??

function repair_timezoneid( $tzid ) {
return “Europe/Berlin”;
}
add_filter( ‘amr-timezoneid-filter’, ‘repair_timezoneid’ );

Bye, Joerg

Glad you got it sorted for you.

Googling android timezones, I still didn’t see the GMT+01.00/+02.00 listed.
I found this: https://gist.github.com/mtrung/a3f7caaa7e674ac7e6c4 – looks like the usual list

Possibly it’s an application, not android itself?
Possibly in the app maybe one could choose a more useful tz?

RE the daylight saving change definitions, they are similar BUT depending on the year could be different.
BYMONTH=3;BYDAY=-1SU – the last sunday of the 3rd month
BYMONTH=3;BYDAY=4SU – the fourth sunday

I guess google must be assuming the Europe/Berlin is more likely to be the correct daylight saving change!

Hi,

this happens even with the build-in calendar app from Google.

Further investigation hints that it is a misunderstanding between Zimbra and Android: When I choose another Timezone far away from Berlin on Android, Zimbra shows it correctly. When I choose one of the +1/+2 zones like Berlin, Bruxelles, Windhoek, even Zimbra itself shows the strange GMT+1/+2 string. Strange too that Android seems to be the only system making these strange events, and all other (tested) clients are doing better.

So I’ll contact our server admins, maybe its a configuration thing in Zimbra or the underlying system.

(My guess is: Android is sending the correct “Berlin” string. Zimbra (other than e.g. the Google Server) is checking the definition of the TZ-definitions, is seeing the difference in BYDAY and then is thinking that “Berlin” is wrong and then is giving these events a self-created “special” time zone. But I have no idea, why only the +1/+2 timezones are affected, and why only android-events…)

Thanx again, greetings, Joerg