Timestamp is not valid. Input seconds is too large

[javisevillano]

Current Behavior

Bug report tip: "OSV Mirroring fails due to 0001-01-01T00:00:00Z date. Java calendar parsing shifts it 2 days before the minimum valid Protobuf Timestamp (-62135596800), causing IllegalArgumentException in ModelConverter.toTimestamp. Needs a boundary check to map to min Protobuf time or null."

Log Output sample:
apiserver-1 | 2026-07-04 11:22:24,908 WARN [ModelConverter] Ignoring invalid published timestamp for advisory DEBIAN-CVE-2026-3842 [vulnDataSourceName=osv]
apiserver-1 | java.lang.IllegalArgumentException: Timestamp is not valid. Input seconds is too large. Seconds (-62135769600) must be in range [-62,135,596,800, +253,402,300,799].
apiserver-1 | at com.google.protobuf.util.Timestamps.normalizedTimestamp(Timestamps.java:473)
apiserver-1 | at com.google.protobuf.util.Timestamps.fromMillis(Timestamps.java:362)
apiserver-1 | at org.dependencytrack.vulndatasource.osv.ModelConverter.toTimestamp(ModelConverter.java:718)
apiserver-1 | at org.dependencytrack.vulndatasource.osv.ModelConverter.convertVulnerability(ModelConverter.java:154)
apiserver-1 | at org.dependencytrack.vulndatasource.osv.ModelConverter.convert(ModelConverter.java:122)
apiserver-1 | at org.dependencytrack.vulndatasource.osv.OsvVulnDataSource.readNextItem(OsvVulnDataSource.java:200)
apiserver-1 | at org.dependencytrack.vulndatasource.osv.OsvVulnDataSource.hasNext(OsvVulnDataSource.java:106)
apiserver-1 | at org.dependencytrack.vulndatasource.MirrorVulnDataSourceActivity.execute(MirrorVulnDataSourceActivity.java:119)
apiserver-1 | at org.dependencytrack.vulndatasource.MirrorVulnDataSourceActivity.execute(MirrorVulnDataSourceActivity.java:65)
apiserver-1 | at org.dependencytrack.dex.engine.ActivityTaskWorker.lambda$process$0(ActivityTaskWorker.java:117)
apiserver-1 | at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
apiserver-1 | at java.base/java.util.concurrent.ThreadPerTaskExecutor$ThreadBoundFuture.run(Unknown Source)
apiserver-1 | at java.base/java.lang.VirtualThread.run(Unknown Source)

Steps to Reproduce

1. In a new installation, Administration->Vulnerability sources->OSV->Mirror now

Expected Behavior

Java exceptions must dissapear in a new installation

Dependency-Track Version

5.x

Browser

Other

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[migus-rs]

I can confirm seeing those in regular OSV imports when the Debian ecosystem is enabled.

A quick looks seems to suggest there was some upstream work to prevent this in the future, but there still seems to be some left-overs:

• DEBIAN-CVE records with published date 01/01/0001 google/osv.dev#4694
• fix: prevent 0001-01-01 published dates in Debian converter google/osv.dev#5149

I guess that leaves two options:

1. Ask OSV upstream to fix affected issues (not sure if possible, as timestamps are already present in dataset)
2. Add a sanity check in DT to avoid the issues

Edit:
Checking the vulnerability list the entry seems to be present despite the warning given on import (and contain affected components), so the parser does not give up outright. Perhaps suppressing the internal exception is the way to go here…

[nscuro]

Right, it's just a warning and caused by upstream data quality issues. The only thing that could use some refinement here is to log something less noisy.