Date management: strange code

Trying to understand the plumbing logic in Gramps, I read carefully the code (version 5.1.4, maybe not the latest but good enough to get the essence of it).

I’m presently studying Date class (gramps/gramps/gen/lib/date.py). This class has a method set(self, …) at line 1583 to check and set a Date object.

Line 1646 call self._zero_adjust_ymd(…) to “sanitize” null values in date (day, month and year adjusted to at least 1). This effectively deletes the “unknown” values encoded as zeroes.

Immediately after this call (line 1651), a test is made to see if all three fields are zero. According to the definition of _zero_adjust_ymd(), the test will never succeed.

Through git, I could trace back this useless test to commit ab7d1210 by Vassilii Khatchaturov on 2013-09-14, inherited from commit de0559e3 by Alex Roitman on 2006-02-03 where it is still present. Unfortunately this commit is a full rewrite of date.py and I can very painfully track back to commit 4cc621cc by Don Allingham on 3006-04-08 which is yet another “beautifier” commit masking previous commits. The “impossible” test is already here.

My question is then:

What is the intent behind this test?

Clearly, we don’t want to compute a sortval if date is not “regular” (as checked by is_regular() which is more logically accurate than the job made by _zero_adjust_ymd()). But even the test year==month==day==0 is not the correct one in presence of uncertainty (supposing uncertainty is not removed by adjustment).

Has anybody experienced problems with uncertain dates?

Note: Date.set(…) is only used in gramps/gramps/gen/datehandler/_dateparser.py

EDIT:
Looking more carefully at _zero_adjust_ymd(self, year, month, day), it appears that it references absolutely no property defined in class Date and returns a tuple created from the arguments. Consequently, shouldn’t this method be downgraded to function status?