Contacts: BDAY format in VCARD, missing "-"

Created on 7 Feb 2017  路  5Comments  路  Source: nextcloud/contacts

Hi,

in the VCARDs BDAY field the "." in YYYY-MM-DD is missing.
(see http://www.evenx.com/vcard-3-0-format-specification)

How to reproduce:

  1. Create contact
  2. Add a date of birth, this will be displayed as "2017-02-01"
  3. Try to find out the contact ID / URI
  4. Get the contacts VCARD with curl:
    curl -k -X GET -u "user":"password" -D - https://"SERVER"/remote.php/dav/addressbooks/users/"USER"/contacts/"VCARD-ID".vcf
  5. The BDAY format is now "20170202"

Thunderbirds AddOn "Cardbook" gives a warning about this format problem in its logfile.

Best regards
Michael

3. to review bug compatibility

Most helpful comment

We should indeed keeps compatibility with 3.0 cards.

rfc2426 reference:

3.1.5 BDAY Type Definition

   To: [email protected]

   Subject: Registration of text/directory MIME type BDAY

   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.

   Type examples:

        BDAY:1996-04-15

        BDAY:1953-10-15T23:10:00Z

        BDAY:1987-09-27T08:30:00-06:00

All 5 comments

Both are accepted according toi the rfc: https://tools.ietf.org/html/rfc6350#section-6.2.5

6.2.5.  BDAY

   Purpose:  To specify the birth date of the object the vCard
      represents.
   Value type:  The default is a single date-and-or-time value.  It can
      also be reset to a single text value.

   Cardinality:  *1

   ABNF:

     BDAY-param = BDAY-param-date / BDAY-param-text
     BDAY-value = date-and-or-time / text
       ; Value and parameter MUST match.

     BDAY-param-date = "VALUE=date-and-or-time"
     BDAY-param-text = "VALUE=text" / language-param

     BDAY-param =/ altid-param / calscale-param / any-param
       ; calscale-param can only be present when BDAY-value is
       ; date-and-or-time and actually contains a date or date-time.

   Examples:

             BDAY:19960415
             BDAY:--0415
             BDAY;19531015T231000Z
             BDAY;VALUE=text:circa 1800

@skjnldsv You used the vCard 4.0 spec to invalidate an issue referencing vCard 3.0.

After reading both of the RFCs, I come to the conclusion that

  • 3.0 uses dashs to separate the year, month and day (section in rfc2425) and
  • 4.0 uses dashs ONLY as placeholders for unknown values (e.g. year or day missing) (section in rfc6350).

We should indeed keeps compatibility with 3.0 cards.

rfc2426 reference:

3.1.5 BDAY Type Definition

   To: [email protected]

   Subject: Registration of text/directory MIME type BDAY

   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.

   Type examples:

        BDAY:1996-04-15

        BDAY:1953-10-15T23:10:00Z

        BDAY:1987-09-27T08:30:00-06:00

@skjnldsv

We should indeed keeps compatibility with 3.0 cards.

Yes, especially when the vcard is in fact 3.0, not 4.0:

> curl -k -X GET -u "user":"password" [...]
BEGIN:VCARD
VERSION:3.0

3.0 uses dashs to separate the year, month and day (section in rfc2425)

To be clear, RFC2425 explicitly states (in section 5.8.2) that its data definitions adhere to the conventions of RFC2234. RFC2234 states that fields enclosed within a [ ] are optional.

The RFC2425 definition of a "date" is given in section 5.8.4:

date = date-fullyear ["-"] date-month ["-"] date-mday

In the context of RFC2234, this means that the following two definitions are both equally acceptable and interchangeable according to RFC2425:

  • 20200618
  • 2020-06-18

For what it's worth, in RFC6350, the standard dropped its own internal definition of the "date" datatype, and deferred to ISO 8601 for a standard textual convention. It turns out that ISO 8601 actually ends up allowing many of the same set of conventions.

As a consequence, the following two definitions are ALSO both equally acceptable and interchangeable in RFC6350:

  • 20200618
  • 2020-06-18
Was this page helpful?
0 / 5 - 0 ratings