How to properly set date created to something before 1900

[EuroCoder]

Hi all,

as I'm using paperless to scan and archive old handwritten letters and documents, for genealogy purposes, I like to set the date created to dates before 1900 or even 1800. My date format ist YYYY-MM-DD.

When I enter a date e.g. 1870-01-01, paperless won't show me the date on the main document site anymore, the field is just empty. The protocol shows no error or warnings at all.

Furthermore, when using one of these unofficial Android apps, it brings an error due to invalid date format (FormatException). As far as I understood, Python should be able to handle old date formats.

Right now, I suspect some issue on the server side. Does anybody ever created and stored documents with old date formats before 1900 (more precisely, the problem starts with dates before 1890, as far as I can tell)?

[stumpylog]

I have no problem setting a very early date:

If you're using an external application, that's something to ask that developer. Paperless will generally only be restricted by either the database or the Python type, whichever is most restrictive.

[EuroCoder]

This is what I will do for sure.

It's just the fact that the date is not shown when I access Paperless via browser what made me look for answers here.

->> Date is 1870-01-01

->> Date as shown

Not having the date shown is quite impractical even when there's no other error or problem raised.

Currently my setup of Paperless is using Postgresql v13. As far as I (or Google) can tell, there should be no problem with this version when it comes to storing old dates. And I'm a little hesitant about updating it, as it seems to be quite complex.

Anything else I could try or should consider?

Thank you!

[stumpylog]

Postgres 13 is getting quite old. It isn't that difficult to upgrade using the export and import.

But I see the issue now, I was looking at a different view. @shamoon any idea why this view might not be able to show the date, but the details can?

[shamoon]

I remember something about this in the past, will see if I can dig it up

#818

Ha, yes its this: dateutil/dateutil#878 (comment)

Will take me a minute to untangle and decide the right type of fix.

[shamoon]

@EuroCoder if youre interested in testing this out there is a docker image with the tag fix-6749 that includes the fix in #6758, but as you can see from the PR I think that'll do it.

That image is based on v2.8.6 so depending on what version youre currently on you may not want to test it against your production data (for example 2.8.0 contains database migrations). If youre already on the latest it's safe to try out. Again, if youre curious.

[EuroCoder]

@shamoon @stumpylog Thanks a lot for your help, I will try this when I'm back home the next days.
But how do I make sure that upcoming updates don't revert or break this fix?

[shamoon]

Im not sure exactly what you mean by "make sure". To clarify the fix above was merged into our dev branch (so if you want to test at this point you should use that tag) and will be included in our next release.

If youre asking about this breaking again in a future regression, then as you've seen here, you can always report it and we'll investigate =)

[EuroCoder]

I see, thanks for the clarification :)

[github-actions[bot]]

This discussion has been automatically closed because it was marked as answered. Please see our contributing guidelines for more details.