First of all I am very happy that Kopano has decided to implement CardDAV! Now I do not need MS Exchange anymore which I cannot get to work on my Android cell anymore since Oreo, so this is great.
However, I have two points of feedback / bugs which need to be ironed out before I can use it productively:
- International characters like german umlaut ä, ö, ß or others like ć are not working for names, addresses, it’s a total mess. They can be stored like that in the webapp, but once transfered to a cellphone it’s not working.
Using export2csv.php file shows that everything is correct, all the umlaute are there. But they appear not to be UTF encoded - my Ubuntu terminal shows a slight difference in how a character is displayed in terminal in case of ASCII or UTF, the later being more “drawn” style and a bit bolder. However, this download works.
To test kdav I used on my Android cellphone:
a) Davdroid - cannot communicate with kdav (but works fine for my Nextcloud Server)
b) contactsync (https://play.google.com/store/apps/details?id=com.vcard.android.free) - works for downloads of contacts. Uploads do do not work well. Looking at the kdav logs I can see that contactsync is sending the VCF data with a “characterset UTF-8” in the HTTP header, but the result is that the kopano database gets data which is not double byte but two single bytes.
- The characters are not “ä” anymore but are two digits which are the two single bytes of the unicode character - export2csv.php also shows the same result
- The contact in the webapp is a new contact if the name was changed causing a different ID (with the old contact remaining)
- Upon a new sync to contactsync the “ä” is now also replaces with the two single bytes
- In turn, upon sycing with kdav the two single bytes which contactsync sends are now each replaced with two new single bytes - so in total taking it from 1 character to 2 characters and now to 4 characters. You can imagine what happens upon the new download and upload I guess?
To me it looks like kopano does not interpret the codepage in which the client sent the data (I can clearly see the double byte character in my terminal as it’s a different visual style as normal) - kdav always converts the input in some way which is wrong / not required causing serious problems.
These are stored as UTC timestamps in Kopano. Nothing wrong with that.
What is wrong however is that these birthdays are not sent in an expected format “YYYY-mm-dd” - they also contain a timezone… This may be OK based on e.g. rfc6474 for “deathdate”. But the problem is that using a UTC timestamp usually triggers code to do a conversion into the timezone of the client - this is the correct behaviour. But this requires that the client and server both “understand” what each one does, if one does it differently then there will be problems.
For me, a contact has the bday “1990-09-05”. This is how I see it in the webapp. When I export this contact it is sent with a UTC timestamp of 4th september 11:00pm. This makes the client set the bday as 4th September. In other cases kdav sends it as 0:00am - no idea why, maybe due to DST?
Now one can start arguing “kdav is doing it right, the client should fix it”. But the trivial approach is just to always STORE the bday in UTC+0 and send the bday as YYYY-mm-dd - without ANY conversion at all to the client. Then there can never be any mixup as no client will do any timezone adjustments as it doesn’t know the timezone.
And another argument - Nextcloud, which also uses sabreDav, works perfectly fine also for the birthdays of my contacts.
This should be trivial to reproduce. TIll these issues are solved, I’m using my Nextcloud Server for my contacts.