<![CDATA[Malformed upload-time (2-digit fractional seconds) breaks pip ≥ 25.3 on Python 3.10]]>Following on from the recent PEP 700 work in PG-3272 / PG-3288 — we've hit a related but distinct issue with upload-time on ProGet 2026.1 (build 14).
The field is now present (good), but the fractional seconds are sometimes serialised to 2 digits, e.g. 2026-04-15T10:23:45.12Z. PEP 700
says the fractional part "may contain up to 6 digits of precision", so this is arguably spec-compliant, but it breaks every Python 3.10 client running pip ≥ 25.3.

The reason: pip 25.3+ reads upload-time on every resolve (for the --uploaded-prior-to feature) and parses it with datetime.fromisoformat. The pre-3.11 implementation of fromisoformat only accepts 0, 3, or 6 fractional digits — 2 digits raises ValueError. Python 3.11+ has the rewritten parser that handles arbitrary precision, so it doesn't reproduce there. PyPI itself always emits 6-digit microseconds, which is why this hasn't surfaced before.
The fix on ProGet's side should be a one-liner: pad/format fractional seconds to either 0, 3, or 6 digits (6 to match PyPI is probably safest).

Repro
Against a ProGet 2026 PyPI feed, with a package whose upload-time happens to truncate to 2 digits (we're seeing it on setup-rebalance):

uv venv repro --python 3.10            # gets default pip 23.0.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# works (pip 23 doesn't read upload-time)

repro\Scripts\python -m pip install --upgrade pip   # -> pip 26.1.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# fails on ValueError from datetime.fromisoformat

Confirming directly in Python 3.10:

>>> from datetime import datetime
>>> datetime.fromisoformat('2026-04-15T10:23:45.123456')  # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.123')     # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.12')      # ValueError

Impact
Anything running Python 3.10 with pip auto-upgraded (which is a common pattern — python -m pip install --upgrade pip is in lots of bootstrap scripts in the wild). Once pip ≥ 25.3 is installed, the env is bricked against any ProGet PyPI feed serving 2-digit fractional upload-time values.

Could you confirm whether this is in scope for a maintenance release? Happy to provide the raw JSON response from our feed if useful — just let me know where to send it.

Cheers

]]>https://forums.inedo.com/topic/5764/malformed-upload-time-2-digit-fractional-seconds-breaks-pip-25-3-on-python-3-10RSS for NodeFri, 29 May 2026 17:54:31 GMTFri, 29 May 2026 13:08:49 GMT60<![CDATA[Reply to Malformed upload-time (2-digit fractional seconds) breaks pip ≥ 25.3 on Python 3.10 on Fri, 29 May 2026 13:10:20 GMT]]>Following on from the recent PEP 700 work in PG-3272 / PG-3288 — we've hit a related but distinct issue with upload-time on ProGet 2026.1 (build 14).
The field is now present (good), but the fractional seconds are sometimes serialised to 2 digits, e.g. 2026-04-15T10:23:45.12Z. PEP 700
says the fractional part "may contain up to 6 digits of precision", so this is arguably spec-compliant, but it breaks every Python 3.10 client running pip ≥ 25.3.

The reason: pip 25.3+ reads upload-time on every resolve (for the --uploaded-prior-to feature) and parses it with datetime.fromisoformat. The pre-3.11 implementation of fromisoformat only accepts 0, 3, or 6 fractional digits — 2 digits raises ValueError. Python 3.11+ has the rewritten parser that handles arbitrary precision, so it doesn't reproduce there. PyPI itself always emits 6-digit microseconds, which is why this hasn't surfaced before.
The fix on ProGet's side should be a one-liner: pad/format fractional seconds to either 0, 3, or 6 digits (6 to match PyPI is probably safest).

Repro
Against a ProGet 2026 PyPI feed, with a package whose upload-time happens to truncate to 2 digits (we're seeing it on setup-rebalance):

uv venv repro --python 3.10            # gets default pip 23.0.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# works (pip 23 doesn't read upload-time)

repro\Scripts\python -m pip install --upgrade pip   # -> pip 26.1.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# fails on ValueError from datetime.fromisoformat

Confirming directly in Python 3.10:

>>> from datetime import datetime
>>> datetime.fromisoformat('2026-04-15T10:23:45.123456')  # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.123')     # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.12')      # ValueError

Impact
Anything running Python 3.10 with pip auto-upgraded (which is a common pattern — python -m pip install --upgrade pip is in lots of bootstrap scripts in the wild). Once pip ≥ 25.3 is installed, the env is bricked against any ProGet PyPI feed serving 2-digit fractional upload-time values.

Could you confirm whether this is in scope for a maintenance release? Happy to provide the raw JSON response from our feed if useful — just let me know where to send it.

Cheers

]]>https://forums.inedo.com/post/19734https://forums.inedo.com/post/19734Fri, 29 May 2026 13:10:20 GMT<![CDATA[Reply to Malformed upload-time (2-digit fractional seconds) breaks pip ≥ 25.3 on Python 3.10 on Fri, 29 May 2026 14:35:18 GMT]]>Hi @appplat_4310,

It shouldn't be a problem to get this in today's release (2026.2). I've logged it as PG-3295.

-Greg

]]>https://forums.inedo.com/post/19735https://forums.inedo.com/post/19735Fri, 29 May 2026 14:35:18 GMT