Support anniversary and other dates

[protist]

Some of my contacts have non-birthday dates. For example, anniversaries, as per RFC 6350 can be specified with ANNIVERSARY:19960415.

My Android contacts app supports anniversaries. When I sync on my computer with vdirsyncer, I see the following snippet in the .vcf file.

ITEM1.X-ABDATE;VALUE=DATE-AND-OR-TIME:20000101
ITEM1.X-ABLABEL:_$!<Anniversary>!$_
X-ANNIVERSARY;VALUE=DATE-AND-OR-TIME:20000101
BDAY:19500101

However, khard does not show this information when editing or displaying the card. I'm not sure, but my understanding is that users should also be able to add arbitrary fields? Is that text in the rfc link? Hence we could add, for example, engagement_anniversary, or death, etc. FWIW OwnCloud uses DEATHDATE:2000-01-01, although this isn't shown in Android's contacts, nor khard. It's apparently covered by RFC 6474.

[scheibler]

I agree. But in general, that's the same problem like for example in issue #105.

Anniversary is officially supported since vcard version 4.0 and a valid entry would be:

ANNIVERSARY:19960415

Your example from Android is entirely self-defined by Google instead. A one-liner would still be
doable but they need three lines for a single anniversary ...

I could support the anniversary attribute for vcard 4.0, no problem there. But that won't help you.
Instead you could end up with different entries - one created by khard using the vcard standard and
another from Android.

It seems, that we need a module, that acts as a compatibility layer between the standard and such private extensions.

[protist]

Hmm… yeah. It looks like it is quite difficult to implement. Coding all the variants wouldn't be ideal.

I'm not sure if it's helpful, but are the following 2 lines a generic way to add arbitrary data to a card? If so, then might that be worth supporting, at least? (From a selfish perspective, I'm actually not even sure what happens if only these two lines get pushed/modified to Android.)

ITEM1.X-ABDATE;VALUE=DATE-AND-OR-TIME:20000101
ITEM1.X-ABLABEL:_$!<Anniversary>!$_

[lucc]

The simplest way to add arbitrary data is a private extension field:

X-FIELDNAME: some data

If you have more dimensional data or want to support different types or formats of data in your extension you start to have more options (and it gets harder to support by others). You can group fields (like the ITEM1 above), you can introduce a semantic to structure the data in your field (like the standard ADR field). And you can probably also abuse the field parameters to store other dimensions of your entry (but they should rather be used to add extra info about the value, like type or encoding):

ITEM1.X-FIELDNAME1: data part 1
ITEM1.X-FIELDNAME2: data part 2

X-FIELDNAME;FOO_DATA=bar: more data

X-FIELDNAME:data part one;and part two;part three has a \; semicolon

Or you can mix any or all of these aproaches. 😢 (your example above does actually mix all: grouped by "ITEM1", there is a "VALUE" parameter and the value X-ABLABEL has some internal semantics, and worse is what the user expects to be the field name)

[protist]

Oh wow, okay. That's horrific. I guess this is Android's idea of "standards". Point(s) taken though; this will be very difficult for khard to deal with.

My initial issue was that I created one of these fields on Android, then attempted to edit it in khard. Because this field was totally absent in khard, I thought there was some kind of problem, and had to check the raw .vcf file.

I'm trying to think of other ways in which khard could deal with this. Perhaps an alternative would be for khard to display raw "unparsed" data, then users could edit this directly? However, I guess it's not ideal, because there's likely a whole bunch of mostly-irrelevant noise that is unparsed.

[lucc]

What about khard source whatever-search-term?

[protist]

Do you mean whatever-search-term in this case would be some string that is contained in… any of the entries? In a way, I probably feel like this would be beyond the scope of khard. The user would have to know the format already, which would probably mean reading a raw .vcf file in the first place… so they might as well edit it there.

I guess that's why I think a raw dump would be one solution, because it makes no presumptions about what the user knows about obscure and non-standard fields. But this obviously has many drawbacks, so possibly better to not even go there.

[lucc]

Please check the help output of khard --help and khard source --help. The subcommand already exists. What do you think is wrong with it and what would you like to implement instead?

[protist]

Oops, sorry, I missed that function. Neat!

So yes, I guess that this probably does as much as khard can be expected to do. It's not ideal, but we're probably beholden to the lack of standards here. Or at least the lack of other applications observing them. The outcome isn't perfect, but I guess this can be closed now, unless there's some other way that khard might deal with all the permutations intelligently. (I'll close it, but feel free to re-open if you want.)

Thank you for the feedback. Cheers.