Allow relative `exclude-newer` values like "one week ago"

[GeoVizNow]

Summary

I am not very experienced with uv yet, but see great benefits with what I have tried.

Benefit of adding functionality to parse natural date into exclude-newer would be to easily be able to keep uv from puling very freshly published dependencies in case of yet to be detected malware.

I would really appreciated to be able to state in pyproject.toml something like below, example:

[tool.uv]
exclude-newer = "one week ago"

or

[tool.uv]
exclude-newer = "14 days ago"

I do not know if this is hard to implement and if it is inconsistent with other configurations. E.g. one would not want this filter to apply for an editable package under development.

Would be interesting to hear your thoughts on this or if this is already being discussed.

[zanieb]

We can't allow this in persistent configuration today because we invalidate the lockfile whenever the exclude-newer value changes. We could consider changing that behavior for this use-case though... it'd be a cool feature.

[GeoVizNow]

Thanks for the fast reply and for considering adding such a feature:). I see there is a challenge with lock files, but great that you see possibilities. This could be one approach to try to tackle the challenge of fresh published malware not detected yet and avoid unintentionally pulling it.

[notatallshaw]

A similar request was made before, #3019, a workaround exists on the command line with Linux:

--exclude-newer $(date --utc -d "7 days ago" "+%Y-%m-%dT%H:%M:%SZ")

[GeoVizNow]

I have experimented a bit automating updating the exclude-newer with code towards pyproject.toml and notice how it could be beneficial to state more details into such a relative natural date string constraint.

If I state "7 day ago at noon" it will set the date string as below and dates will jump with whole days and not seconds.

[tool.uv]
exclude-newer = "2025-07-25T12:00:00Z"

This would help avoiding too eagerly updating the uv.lock and would result in making it update no more frequently than daily (which would maybe be what to prefer) due to this constraint.

[BurntSushi]

A point against things like 7 days ago in persistent configuration is that it lacks a time zone. Does that mean 7 days ago in UTC? Or in the time zone of whoever is running uv? This is why we require a specific and unambiguous timestamp in pyproject.toml (e.g., RFC 3339) but, IIRC, allow things like 2025-08-01 on the CLI where it's more obvious that the system's configured time zone would be used to resolve that civil date to an instant in time. On that token though, I think it would be cool to allow things like 7 days ago on the CLI.

[zanieb]

Isn't 7 days ago the same time regardless of the time zone?

[zanieb]

(of course, it's probably not once you start dealing with DST?)

[BurntSushi]

DST is part of it, but "7 days ago" is a relative datetime. So from which point do you start counting? If you start at the current UTC time you'll end up at a difference place than if you started with the current time on the East coast in 5 out of 24 hours in the day (or 4 during DST).

[GeoVizNow]

I can easily see that details around time zone could lead to problems in the the details that must potentially be but solved somehow. The intention of this issue was to hopefully being able to leverage another method to tackle the ever increasing challenge of not-yet-detected malicious packages with malware. The main idea would be to secure a delay such that the risk of installing malicious sofware decreases due to chance of discovery is higher when putting a such a delay that gives researchers more time to detect issues.
Thus I think that the date is the important constraint. Maybe one could assume UTC as a default time zone as a simplification when/if relative date is used in configuration files (is UTC what is used for pypi package publish date?).

[BurntSushi]

IMO, we shouldn't assume UTC for datetimes (relative or not) without a time zone or an offset stored in a persistent configuration file. I think it makes it too easy for readers of the configuration to assume local time instead of UTC.

(is UTC what is used for pypi package publish date?)

upload_time is a timestamp that is compatible with both RFC 3339 and ISO 8601. It has a time zone offset indicating UTC (Z), so no assumption of implied UTC is required.

[notatallshaw]

Apologies, this is a slight aside, but I was thinking about assuming UTC for pip when a timezone isn't provided for the non-relative exclude newer so that it produces the same result across environments: pypa/pip#13520

In terms of relative difference, you need to decide when it comes to a DST change over does "1 day ago" mean the same as "86400 seconds ago". This is clearly subjective as different datetime libraries have different solutions (this has been somewhat a discussion on DPO since utcnow was deprecated). One solution is perhaps to offer very limited relative syntax so o ky one way can be described.

[BurntSushi]

@zanieb and I were talking about something like 2 days ago in UTC or 2 days ago in America/New_York. A bit more verbose, but much less ambiguous.