Birthdate format not properly processed for VCARD 3.0
There still seems to be some bug in processing the birthdate field.
CardBook seems to enforce the date format YYYY-MM-DD now when saving a contact in a VCARD 3.0 (RFC2426) address book. Other formats (e.g. YYYYMMDD) result in an error message that saving is not allowed. Moreover, when the dates from a VCARD 3.0 address book are displayed in the contacts list, only dates of the form YYYY-MM-DD are formatted according to the configured date format setting. Dates of the form YYYYMMDD are left as-is.
However, this clearly violates RFC2426 which allows the BDAY field to contain a single "date-time-value" or "date-value" (see 3.1.5 BDAY Type Definition and 4. Formal Grammar):
Type name: BDAY
Type purpose: To specify the birth date of the object the vCard
represents.
Type encoding: 8bit
Type value: The default is a single date value. It can also be reset
to a single date-time value.
;For name="BDAY"
param = ("VALUE" "=" "date") ; Only value parameter allowed
param =/ ("VALUE" "=" "date-time") ; Only value parameter allowed
value = date-value ; Value MUST match value type
value =/ date-time-value ; Value MUST match value type
The RFC in turn defines "date-time-value" and "date-value" to be in accordance with RFC2425 (see 4. Formal Grammar):
date-value = <A single date value as defined in [MIME-DIR]>
date-time-value = <A single date-time value as defined in [MIME-DIR]
RFC2425 defines "date" as (see 5.8.4. Pre-defined Value Types):
date = date-fullyear ["-"] date-month ["-"] date-mday"
Hence, the dashes are optional. In fact, that grammar would even allow some rather odd variations, like YYYYMM-DD and YYYY-MMDD.
For VCARD 3.0 address books, CardBook should therefore properly parse dates with or without dashes for any existing contact and display those dates in the localized format that was chosen in the settings.
Moreover, when saving new/updated contacts, CardBook should allow any of these formats. This could either be done by simply using the format that the user typed into the birthdate field, or by automatically normalizing the field into one of the formats. However, if the latter method is used, care needs to be taken that other programs (or the server itself) might normalize the date into a different format, e.g. if CardBook chooses to always use "YYYY-MM-DD" other clients might still always use "YYYYMMDD" (e.g. DAVx5 for Android enforces that format). Consequently, receiving VCARD where only the date format was changed into another valid format must not trigger updates/synchronization of the contact with the server (since this would potentially lead to infinite update loops).