• General
  • iPhone Calendar invites and incorrect time zones

I'm having some issues with calendar invites. I have 2 users in my Grommunio community system. Both users are using iPhones with ActiveSync and Outlook on windows connected by MAPI. Both users and all their devices as well as the Grommunio appliance are in the US Eastern time zone and are configured as such. When either user invites the other to an event they create using their iPhone the event shows as GMT in the other persons Outlook and thus shows the event occurring 4 hours later than reality. The event shows properly on all iPhones and properly in the creators Outlook. It seems something is wrong with the way the invitation is being crafted. I also tested inviting an outside user using MS Office 365 to an event I create using my iPhone and my Grommunio account, the invite works properly for them. I also note that in the Outlook invitation they get there's a message saying "This meeting has been adjusted to reflect your current time zone. It was initially created in the following time zone: tzone://microsoft/Utc". I don't get this notice on invitations sent to my Grommunio account. So it appears Microsoft Office 365 is doing some processing to correct this issue before it gets to the user?

It's important to note that this issue only occurs with recurring events. This also only happens with invites created on the iPhone, if I create the event in Outlook on Windows everything is fine. Any idea what's going on here?

Also worth noting that these problematic events show properly in the Grommunio web interface. So it's just events created on the iPhone and then viewed in Outlook. Also, I have an Office 365 account to test with and when I create events using that account on my iPhone they work properly. So this is definitely an issue unique to Grommunio.

    7 days later

    Todd1561

    it´s a problem between outlook and grommunio. I also faced issues with timezone in grommunio calendar.
    E.g. i create a full day appointment in grommunio and on my android phone (i use Nine Mail App) the appointment is shown correctly. But in outlook the appointment is shown one day earlier. If i change the appointment from a full day appointment to an appointment from e.g. 26.08. 00:00 to 29.08. 00:00 it´s shown correctly in outlook.

    If i create a full day appointment in outlook, for e.g. friday the appointment in grommunio starts on friday 2:00 and ends on saturday 2:00 so there is ashift of 2 hours and it looks like this:

    On my Debian 12 server i use the timezone CEST (UTC +2) and it seems that the full day appointments are set to UTC which causes this shift of 2 hours.

    There are several posts in the grommunio community forum which report issues with timezone in calendar appointments.

    Thanks for the reply. This is disappointing, I've jumped around to a couple different email/groupware systems for my small home deployment because everything I've tried seems to have some problem with calendaring. I was hoping Grommunio was going to solve that. I'm not sure why calendaring is so difficult to nail down.

    What are you doing as a workaround? Your situation doesn't even sound usable. I haven't had any problems with regular events, whether "all day" events or not. The only issue I've seen are invites to recurring events.

    It's too bad because you really start to lose confidence in the system when problems like this occur. I keep a lot of important meetings and events in my calendar and depend on it to remind me properly. :/

    I notice I get this error in the /var/log/grommunio-sync/grommunio-sync-error.log file when creating an event:
    /usr/share/grommunio-sync/lib/grommunio/mapiprovider.php:2353 unpack(): Type l: not enough input, need 4, have 0 (2)
    /usr/share/grommunio-sync/lib/utils/timezoneutil.php:1143 Trying to access array offset on value of type bool (2)
    TimezoneUtil::FillTZNames() submitted TZ array does not have a bias
    /usr/share/grommunio-sync/lib/utils/timezoneutil.php:1284 Trying to access array offset on value of type bool (2)
    /usr/share/grommunio-sync/lib/utils/timezoneutil.php:1285 Trying to access array offset on value of type bool (2)
    /usr/share/grommunio-sync/lib/utils/timezoneutil.php:1287 Trying to access array offset on value of type bool (2)
    /usr/share/grommunio-sync/lib/utils/timezoneutil.php:1288 Trying to access array offset on value of type bool (2)

    3 months later

    I think I have this solved! The short answer is I set the define('TIMEZONE', ''); line at the top of the /etc/grommunio-sync/grommunio-sync.php file to define('TIMEZONE', 'UTC');. And restarted the gromox-http service. I also initiated a EAS resync in the admin portal for my 2 users for good measure. Now all invites look good on all devices and I even get the notice in the invite that shows in Outlook that says "This meeting has been adjusted to reflect your current time zone...." like I was getting for invites sent from my Office 365 account. This also fixed the issue I was having with all-day events spilling over into the day after the event, which I think is the issue @kslt90 was having.

    What clued me into this was when looking at the grommunio-sync logs all the timestamps were 1 hour ahead of UTC. I'm in New York, USA timezone so it didn't make sense that the time stamps weren't either UTC or New York. Then I stumbled across that setting in the PHP file and first hard set it to New York time zone and then I had the opposite problem. All-day events were now spilling into the preceding day instead of the following day. This told me that this setting was indeed critical to the operation of EAS. I then hard coded that setting to UTC and everything seems to be fixed! It's worth noting that in every other area I'm aware of in Grommunio that has to do with timezones I have it set to my local New York zone. So why this EAS config needs to be different I do not know, but it seems to be working.

    Maybe someone from Grommunio can chime in about the purpose of this timezone override setting?

      8 days later

      Todd1561

      Hi,

      are you using the appliance? If I'm not mistaken there the timezone is set to Europe/Vienna (CET). That's the time zone which grommunio-sync uses if an appointment or meeting doesn't have a time zone associated with them. 'TIMEZONE' in grommunio-sync config.php overrides the server's setting.

      For all-day events the mobile devices usually don't send the time zone information, just the timestamp of the midnight in UTC. The clients then adjust that automatically to be all-day event (from midnight to midnight) in their time zone. That's usually fine because you want it to be an all-day event regardless of the time zone you're currently in.

      All-day events get tricky when there are attendees in various time zones. E.g. you setup an all-day event with someone in Vienna and Tokyo. For you in New York it's from midnight to midnight, but in Vienna it's from 6AM to 6AM and in Tokyo from 2PM to 2PM otherwise they would miss the meeting by 6 and 14 hours respectively (the time difference may not be accurate all the time, but you get the idea).

      Another issue which might occur for events is that the time zone information was not saved. E.g. you create an event at 2PM New York time which is 7PM UTC. grommunio-sync then gets the 7PM UTC timestamp, but because there was no timezone information and the timezone on the server is Europe/Vienna, grommunio-sync adds 1 or 2 hours bias and saves the appointment at e.g. 8PM UTC.

      It gets even more complicated with the recurring events when it's necessary to take into account standard and daylight saving changes over multiple time zones. Not every time zone has a daylight saving time, and some time zones have different daylight saving/standard time changes depending on a year.

      Finally, there are clients like mobile devices which might not have implemented the time zone handling properly.

      I hope that explains a bit why the calendaring it's not so easy to nail down 🙂

      Yes I'm running the appliance, ISO installed as a Hyper-V VM. Vienna is 1 hour ahead of UTC, so that would explain the timestamps I was seeing in the logs being an hour ahead and apparently the issues with calendaring. What's the logic behind hard coding Vienna time just for EAS? That doesn't really make sense to me and seems like it breaks the system for a vast majority of users? The Grommunio setup has a designated facility to configure a timezone, seems like that should apply in all areas of the software, no? Or at least just use UTC.

      Are you saying the system should be working out of the box without having to make that timezone override in the EAS PHP config file? Because that definitely wasn't the case for me. Calendar events were all over the place with the events showing correctly on the device that created it but syncing up to the server and other clients incorrectly.

      Anyway, I originally just wanted to report back to mention that PHP setting as it seemingly cleared up things up for me and to potentially help others down the road. It also seems like if that setting were defaulted to UTC out of the box it could potentially fix issues for a lot of people.

        Todd1561

        Todd1561 What's the logic behind hard coding Vienna time just for EAS?

        I suppose I wasn't clear enough. As far as I know this setting is default for the appliance itself, e.g. when you type date on CLI. Unless you configured some different time zone when setting up the appliance.

        Todd1561 That doesn't really make sense to me and seems like it breaks the system for a vast majority of users?

        Well, the vast majority of the grommunio users probably are in Western Europe, so I'd say it works fine for the most of the users 🙂.

        Todd1561 The Grommunio setup has a designated facility to configure a timezone, seems like that should apply in all areas of the software, no? Or at least just use UTC.

        grommunio-sync (and also grommunio-web and grommunio-dav) are PHP applications and they might get the time zone setting e.g. from php.ini which might differ from the system setting.

        Todd1561 Are you saying the system should be working out of the box without having to make that timezone override in the EAS PHP config file?

        Just a clarification, grommunio-sync (or g-sync for short) implements ActiveSync protocol, that is grommunio's equivalent to Exchange Active Sync. The term EAS is specific for Microsoft.
        I would expect that there's no need to change the 'TIMEZONE' value in config.php of grommunio-sync in order for the appointments to appear on correct times. It definitely worked for me in the past with different time zones.

        Todd1561 Anyway, I originally just wanted to report back to mention that PHP setting as it seemingly cleared up things up for me and to potentially help others down the road. It also seems like if that setting were defaulted to UTC out of the box it could potentially fix issues for a lot of people.

        Thanks for the feedback. That is good to know and might help the others should they encounter such issue.

        © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice