[BUG] Datestamp in Downloaded file is one day off

[amenk]

Describe the bug

When the created data is 30.10.2021, the downloaded file name is "2021-10-29 My Invoice".pdf

To Reproduce Steps to reproduce the behavior:

1. Go to document
2. Set created data to 30.10.021
3. Press download
4. See wrong filename

Expected behavior

The file name should have the same date as the created data.

Relevant information

• Docker / Paperless-ng 1.5.0
• I believe I did not make any timezone configuration (no docker variables set)
• I am in Europe/Berlin time zone
• There was a Day Saving Time shift this night, but the document was created after the shift

Other existing issues

The root cause is probably very similar to https://github.com/jonaswinkler/paperless-ng/issues/1141, but I don't use the Europe/Berlin time zone. Also there is https://github.com/jonaswinkler/paperless-ng/issues/872

Possible solution

I believe the date is currently stored as datetime in the database. In the UI there is only a date displayed. So why store a DATETIME at all? Storing just a data should avoid those problems alltogether.

[titro]

Try to set paperless environment in docker compose: PAPERLESS_TIME_ZONE: "Europe/Berlin"

[amenk]

Shouldn't be the date display consistent, regardless of the time zone?

[titro]

agree. Don't know the code but what i noticed: timestamp is stored with time (usually with time 00:00:00) in database.

If i don't use timezone environment, the downloaded files become a date -1 if i use Europe/Berlin, everything is fine.

If i change the time to a higher value than the diff utc / Europe/Berlin (vor example 10:00:00), everything is fine.

What i assume: The client timezone is used, also as a "base" for the document timestamp and during processing a utc timestamp is used. And a timestamp with time 00:00:00 becomes current time -1 so current date -1

[darkmattercoder]

Just saw the same. However, manually invoking the document_renamer will work

[MMauro94]

Just saw the same. However, manually invoking the document_renamer will work

That's strange, I have the exact opposite problem.

I'm using the jonaswinkler/paperless-ng docker image on the latest version (1.5.0) with the following config:

environment:
  PAPERLESS_TIME_ZONE: Europe/Rome
  PAPERLESS_FILENAME_FORMAT: "{correspondent}/{document_type}/{created_year}/{created_year}-{created_month}-{created_day} - {title}"

If I save a document, for instance, with the creation date on 19/03/2015 it's correctly saved as 2015-03-19 - name.pdf. But if I run document_renamer all documents get shifted one day prior (in this case 2015-03-18 - name.pdf). If then save the document again, the correct date is restored.

I also tried, to no avail, to add the following config to the container:

volumes:
  - /etc/localtime:/etc/localtime:ro
  - /etc/timezone:/etc/timezone:ro

[amenk]

@MMauro94 yes, My timezone config is default (probably UTC), while yours is Europe/Rome

I think the date should just be stored in the database as date-only field without any time, this could solve it. But I did not look into the code as well.

[MMauro94]

From what I can tell by exploring the SQLite database, the dates are stored in UTC.

A few samples from my DB:

created	strftime('%s', created) (Unix epoch)	Creation date from UI
2014-09-09 22:00:00	1410300000	2014-09-10
2015-03-18 23:00:00	1426719600	2015-03-19
2022-03-07 23:00:00	1646694000	2022-03-08
2021-06-30 22:00:00	1625090400	2021-07-01

So the app, when saving a date, would do the following:

• Take the date input from the browser (e.g. 2014-09-10)
• Set to midnight (e.g. 2014-09-10T00:00)
• Set timezone (e.g. 2014-09-10T00:00+02:00[Europe/Rome])
• Convert to UTC and save (e.g. 2014-09-09T22:00Z)

My guess, for my specific problem at least, is that the document_renamer simply doesn't convert back from UTC to the environment timezone when renaming documents.