lyallp

Nextcloud 25.0.3 and Calendar 4.4.2 still exhibit this behaviour, as in shows Sunday as the left column in the calendar, when first day of week is Monday (English - Australia)

Change if (preg_match('/^[\\p{L}\\p{M}\\p{N}\\p{P}\\p{S}]$/u', $c)) { to if (ord($c) < 128) {

Same applies to RELATED, parameters are soaked up into TYPE. Possibly a generic problem with TYPE interpretation? I suspect this is related to issue nextcloud/server#1845 from ``` RELATED;TYPE=parent,VALUE=text:aaaaaaaaa RELATED;TYPE=brother,VALUE=text:bbbbbbbbb RELATED;TYPE=sister,VALUE=text:ccccccccc...

Interesting that PREF causes loss of TYPE but TYPE soaks up everything behind it into a useless value that is lost/discarded down the track, by clients that sync and discard...

> In your linked RFC the PREF is separated with a ;, not with a ,. Good call! Using a `;` produces a much better result. On the iPhone, things...

PREF defaults to value 1, if no value supplied. Really beginning to suspect CardBook as post CardBook edit (with nothing changed) `PREF=10;TYPE=OTHER` became `TYPE=PREF;TYPE=OTHER` in addition to the second postal...

All references in my post are for vCard 3.0 as per RFC [6350](https://tools.ietf.org/html/rfc6350) Basically PREF is an ordering field and has nothing to do with TYPE. TYPE can still have...

**Whoops**, you are entirely correct, so..., Contacts exports contact vcf files with vCard 4 entries yet labels the file with a `VERSION:3.0`

I exported a contact from NextCloud Contacts and tweaked entries manually. I then deleted that contact from NextCloud then imported the file I Manually tweaked, with the incorrect VERSION as...

I found that if I import a v4 vCard into NextCloud contacts, refresh and immediately download the contact, the download is converted to v3 vCard including removal of PREF fields...