release_date deserialization errors when upload-time metadata is missing

[barometz]

Hi! I'm trying to get simple-repository-browser to work with Artifactory's PyPI repositories. Searching and loading projects works fine, but at some point the application tries to retrieve project info from its cache and I get

  File "/home/user/pybrow/.venv/lib/python3.11/site-packages/simple_repository_browser/controller.py", line 112, in search
    response = await self.model.project_query(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/pybrow/.venv/lib/python3.11/site-packages/simple_repository_browser/model.py", line 154, in project_query
    results = cursor.execute(sql_query, params).fetchall()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/share/uv/python/cpython-3.11.13-linux-x86_64-gnu/lib/python3.11/sqlite3/dbapi2.py", line 68, in convert_timestamp
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
    ^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: b'00+00'
2025-09-26 14:37:50,083 [uvicorn.access] INFO:     127.0.0.1:37454 - "GET /search?query=simple-repository-browser HTTP/1.1" 500 Internal Server Error

(full session logs at tz-stacktrace.txt)

The exception seems to be caused by an unexpected UTC offset in the release_date timestamp in projects.sqlite. When I open the cache, all the timestamps are 1970-01-01 00:00:00+00:00. As far as I can tell the upload_time attribute is never set, so the timestamp gets default-inserted in a way that includes the UTC offset, while normally the cache would use naive timestamps.

I'd like to work on this, but I'm having a hard time seeing where the upload-time is supposed to come from when not using the JSON format.

[pelson]

Thanks for the report, and digging into it. Sorry the codebase is still a bit of a maze - we are gradually trying to tidy it up. In fact, there was a change a few months back relating to metadata extraction (https://github.com/simple-repository/simple-repository-browser/pull/18/files) in which we pulled out size determination into its own simple-repository "component". Unfortunately, we haven't yet done that with upload_time. By the looks of it, there aren't too many places where it is touched. The key location for extending the upload time beyond what the package repository natively gives us is:

https://github.com/simple-repository/simple-repository-browser/blob/main/simple_repository_browser/fetch_description.py#L196

This is injected into the database at:

https://github.com/simple-repository/simple-repository-browser/blob/main/simple_repository_browser/crawler.py#L187

The first thing to find out is whether the timestamps are being provided to you by the underlying package repository. If not in the PEP-503 http responses, perhaps there is another way to augment this information - for example, does the HTTP headers of the resources (e.g. wheels) have any useful information?

In the past, I have used timestamps of files inside the wheel/sdist themselves to provide a reasonable approximation of release date. Writing a component to do this would be possible (it has the downside of only being available after looking at the file itself though).

All of the above is in the interest of improving your metadata for a nicer experience. In simple-repository-browser, it would be great to make it more robust when setting timestamps in the first instance. It could very well be that there is a bug on the parsing level in simple-repository (e.g. https://github.com/simple-repository/simple-repository/blob/affa349b53a24ed6e3e38e55275b4866576f129e/simple_repository/parser.py#L74)

Let me know if you have any questions, or need any more pointers 👍

[pelson]

I think this got fixed in #32. Please could you clear the DB and try again?