This all might be a regression, looking at Bug 11846 from 2014. To recreate: - have a patron - create a manual restriction for your patron, entering a reason but not a date - confirm that the patron account shows your restriction with an expiration date of "indefinite" - in reports, SELECT * FROM borrower_debarments WHERE borrowernumber= [your patron] - confirm borrower_debarments.expiration is null - in reports, SELECT * FROM borrowers WHERE borrowernumber= [your patron] - confirm borrowers.debarred='9999-12-31' This will cause a lot of issues in 7,977 years. Here in the year 2022, it's generally incorrect and confusing to be using a far-future date to denote "indefinite," and is made more confusing by the fact that borrowers and borrower_debarments don't handle it the same way. This also means one cannot create indefinite debarments via patron import. If one's CSV contains a debarredcomment value without a debarred value, no restriction is created. If one's CSV contains a debarred value of '9999-12-31,' that is treated literally and the restriction is given an expiration date of '9999-12-31.'
To widen the scope of this a bit, we could perhaps consider if it makes sense to record debarments/restrictions both in the borrowers table, and in the dedicated borrower_debarments table? Would it not make more sense to have them only in the borrower_debarments table, since there can be multiple debarments per patron?