<![CDATA[Cargo package metadata contains invalid date format]]>Hi,

We recently upgraded to the latest Proget version 2026.0.7 and are facing an issue where all of our non-cached cargo builds are now failing.

I have managed to create the following minimal reproducible example (assumes a configured Proget crates.io proxy feed called cargo-proxy):

export CARGO_REGISTRIES_CARGO_PROXY_INDEX='sparse+https://<PROGET_URL>/repository/cargo-proxy/'
cargo init --name example
echo 'libssh2-sys = "0.3.2"' >>Cargo.toml
CARGO_LOG=cargo::sources::registry=info cargo --config 'source.crates-io.replace-with="cargo-proxy"' build

The full error message is as follows:

    Updating `cargo-proxy` index
   0.110223098s  INFO cargo::sources::registry::index: recoverying from failed parse of registry package libssh2-sys@0.3.2: strptime parsing failed: %m failed: failed to parse month number: parameter 'month' with value 34 is not in the required range of 1..=12 at line 1 column 1305
error: failed to select a version for the requirement `libssh2-sys = "^0.3.2"`
  version 0.3.2's index entry is invalid
location searched: `cargo-proxy` index (which is replacing registry `crates-io`)
required by package `example v0.1.0 (/tmp/tmp.XZhfnMUE6V)`

After looking at the date value for various packages/versions, I noticed that the month field always seems to have the same value as the minute field. I'm thinking that maybe the month value is using the mm specifier instead of the MM specifier.

Thanks,
Joris

]]>https://forums.inedo.com/topic/5810/cargo-package-metadata-contains-invalid-date-formatRSS for NodeMon, 10 Aug 2026 09:14:48 GMTFri, 07 Aug 2026 03:47:36 GMT60<![CDATA[Reply to Cargo package metadata contains invalid date format on Mon, 10 Aug 2026 02:25:10 GMT]]>Hi @rhessinger,

We have now upgraded to 26.0.8 and are still facing a very similar error.
I can confirm the month field is now correct but comparing the pubtime value to crates.io think the end of the field is incorrect.

From https://doc.rust-lang.org/cargo/reference/registry-index.html:

The format is a subset of ISO8601:
- `yyyy-mm-ddThh:mm:ssZ`
- no fractional seconds
- always `Z` for UTC timezone, no timezone offsets supported
- fields are 0-padded
Example: 2025-11-12T19:30:12Z

For reference proget is returning: 2026-06-30T19:34:05.265596Z (note the fractional seconds).

Thanks,
Joris

]]>https://forums.inedo.com/post/19930https://forums.inedo.com/post/19930Mon, 10 Aug 2026 02:25:10 GMT<![CDATA[Reply to Cargo package metadata contains invalid date format on Mon, 10 Aug 2026 00:50:46 GMT]]>Hi @rhessinger,

I see that 26.0.8 has now been released.
Thank you for the quick turn-around, we are upgrading now.

Joris

]]>https://forums.inedo.com/post/19929https://forums.inedo.com/post/19929Mon, 10 Aug 2026 00:50:46 GMT<![CDATA[Reply to Cargo package metadata contains invalid date format on Fri, 07 Aug 2026 13:06:01 GMT]]>Hi @joris.guex,

Thanks for bringing this to our attention. I have created a ticket, PG-3344, to track the fix and I'll be able to get in in with today's release. Here is a prerelease build of ProGet 2026.8 that includes the fix:

https://proget.inedo.com/containers/tags/ProductImages/inedo/proget/26.0.8-ci.4/overview

Thanks,
Rich

]]>https://forums.inedo.com/post/19915https://forums.inedo.com/post/19915Fri, 07 Aug 2026 13:06:01 GMT<![CDATA[Reply to Cargo package metadata contains invalid date format on Fri, 07 Aug 2026 04:35:00 GMT]]>In the meantime, what are the chances that downgrading Proget to 2026.0.3 would work? For context we are running Proget using docker with an external Postgres database. Are there changes to the database that would prevent this from working?

Alternatively, could you please provide an approximate timeline for this getting fixed? We are happy to use a non-release build with the fix included if that helps.

]]>https://forums.inedo.com/post/19911https://forums.inedo.com/post/19911Fri, 07 Aug 2026 04:35:00 GMT