DeprecationWarning on python3.13

[jamm1985]

khard ls <name> leads to:

/usr/bin/khard:8: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
  sys.exit(main())

<khard responce>

[lucc]

Hey @jamm1985, can you provide a vcard to test this or can you find the exact line number and input that produces this warning?

(By they way: PR welcome :)

[ryspace]

I actually get this same deprecation warning with any show, list, or edit command for any contact.

[andrewferrier]

Agreed with @ryspace, this happens for me (for example) with khard email --parsable <anystring>. I don't think it's specific to a particular contact.

Judging by the deprecation warning being produced, my guess would be that khard is parsing a date without a year (perhaps a birthday field?).

[andrewferrier]

OK, I've narrowed this down further, which may help. I have reduced the number of .vcf files in the addressbook path to only one, and that file contains (personal details changed for obvious reasons):

BEGIN:VCARD
VERSION:3.0
PRODID:-//Apple Inc.//iOS 15.5//EN
UID:FDEA87E4-B665-47F3-9A60-358127EA81C5
BDAY;VALUE=date:2002-04-16
FN:FirstName LastName
N:LastName;FirstName;;;
REV:2022-06-25T16:27:50Z
END:VCARD

I suspect this is also Python-version sensitive; I am using Python 3.13.1

Edit: Further information, it looks like it's the BDAY field. If I remove that manually from the .vcf file, the error disappears.

[andrewferrier]

OK, I believe I've narrowed this down a bit more. It's not the birthday field per se I believe, but the way khard is parsing dates. If I modify this line in my khard installation to remove the first two date formats (which are the ones without years), the error disappears.

So it looks like the error is on the face of it 'correct'; khard is (attempting to) parse dates without a year component, presumably so you can gracefully accept whatever's in that field, but Python doesn't want you to do that because it leads to leap year corner-cases (see the linked issue in the error message).

I'll wait for further comment here; if there's an easy fix I'm happy to create a PR, but I'd like to understand what you want to do to fix first.

[lucc]

The vcard standard explicitly allows dates without years (https://datatracker.ietf.org/doc/html/rfc6350#section-4.3) but the python datetime class does not (see the issue linked from the deprecation warning).

I think the correct way to handle this would be to extend the types that khard uses to use datetime|PartialDate instead of datetime. Here PartialDate would be a class that represents the partial date values that are allowed by vcard but not by datetime. Any thoughts?

Note for whoever is motivated to work on this: I think it is beneficial to add tests for yaml editing of partial dates and display of partial dates with the new types.

[andrewferrier]

I'm not familiar enough with the flow of that logic in khard right now to have a strong opinion, but I would note that the Python developers seem to suggest a different approach, which is a default year: python/cpython#116179. If you picked a ridiculously old leap year (e.g. 1584, the first ever leap year in the Gregorian calendar) and then removed it again later for presentation etc., would that work? Maybe this does need a wrapper type...

Unfortunately right now I don't personally have time to work on it, but let's keep the issue open and I may come back to it if I can.