iPhone 3.0, CalDav, & the year 2145

[avatarr]

There is some discussion in this thread about this issue but the thread itself starts off with a different question so anyone simply reading through might miss it, so I figured I would start another thread for this issue specifically. It seems that I am one of at least three people who are experiencing this issue. When configuring caldav on the iPhone, one of two things happens depending on the account method used.

I should mention that my email address has a different domain than the zimbra server domain; so the zimbra is at zimbra.domain1.com and my email address associated with that zimbra account is me@domain2.com - I don't know if this is important or not, but I wanted to just mention it. So below, your.zimbraserver.com is not the same domain as the email address doman, "domain.com".

With full email address (method 1):
Server: your.zimbraserver.com
User Name: firstname.lastname@domain.com
Password: <password>
Advanced Settings...
Use SSL: Yes
Port: 443
Account URL: https://your.zimbraserver.com/princi...ame@domain.com
-- I should note that after entering the above into the box, it changed it to read: https://your.zimbraserver.com:443/pr...%40domain.com/

Without full email address (method 2):
Server: your.zimbraserver.com
User Name: firstname.lastname
Password: <password>
Advanced Settings...
Use SSL: Yes
Port: 443
Account URL: https://your.zimbraserver.com/princi...tname.lastname

The problems:
With method 1, the calendar shows up in the calendar listing, but all entries that were there before span through the year 2145, and show up as taking up the entire day from now through to the year 2145. They also show as having grayed out and dashed line borders in the calendar view.

With method 2, the account verification is successful, where presumably it checks the server to make sure the login is good. After going through all the settings, however, I go to view my calendar and the Zimbra calendar that I just set up in "Settings" doesn't even show in the list of available calendars.

[ewilen]

I just downloaded 3.0 on my iPod touch to test the new features. I used method 1 and everything seems fine (with one exception, see below). It was not necessary to enter the Account URL--I just entered Server, User Name, and Password, then corrected the port for SSL to 443. The Account URL was created for me and agrees with what you got, with the %40, which is standard URL encoding for the @ symbol.

The account URL for method 2 doesn't seem right. Given that you are on a different domain within Zimbra, I don't see how your account URL could just have your username without domain name. Think about it: if you had two people with the same username but different domains, how would Zimbra know which one to supply to your iPhone's CalDAV client?

My single issue is that after finding that iPhone 3.0 lets you have online calendars without deleting your local calendar, I turned on ActiveSync as well as CalDAV. Then I did an iTunes sync (via USB) to my Mac because I wanted to try the new Notes sync feature (it works, by the way, syncing iPhone Notes with Notes inside of Mail). At some point this caused my local copy of iCal to show duplicate events in my Zimbra calendar.

However, Zimbra web client didn't show duplicate events. So, I deleted the CalDAV account in iCal and recreated it. This redownloaded the data from the server and got rid of the duplicates.

[jpierson]

I'm having the same problem. Several events come in when using CalDav with end dates in 2145. I believe they were recurring events with no end date in Zimbra?

A sync using the activesync protocol doesn't generate these weird appts. I can use that for now and grab my Google calendars with CalDav.

[ewilen]

Some discussion and analysis of the 2145 issue is also here: Bug 30950 - iphone: sync with shared contacts and calendars

[dgcassidy]

I'm experiencing the same issue with our Zimbra-based calendars. Some events -- seemingly only invitations sent to me (and received via Zimbra) by Outlook users -- have exactly the same duration of 49,710 days, 3 hours, and 28 minutes (which is 4,294,956,480 seconds, or 71,582,608 minutes, or 1,193,043 hours).

This CANNOT be coincidence. There's clearly a repeatable bug here.

To verify this, put your meeting start and end dates and times into this page -- Time Duration Calculator: Time between two dates/times -- and it'll figure it out for you automagically.

We haven't been able to diagnose this yet, but it's making the use of CalDAV very unattractive right now.

Meanwhile, Google calendars are CalDAV'ing beautifully. Love the live updates!