KEV's dateAdded is a plain calendar date with no time or zone, while the KEV release time, the EPSS score date and OSV's modified field are UTC timestamps. Convert everything to UTC dates before you compute ages, windows or "per day" counts, or your results can be off by one day.
What each source gives you
Read from the files fetched on 19 October 2026:
| Source | Field | Example | Notes |
|---|---|---|---|
| KEV | dateAdded | 2026-10-16 | Date only, no time zone |
| KEV | dueDate | 2026-10-19 | Date only |
| KEV | dateReleased | 2026-10-16T17:15:48.8752Z | Timestamp ending in Z, meaning UTC |
| EPSS | score_date | 2026-10-18T12:03:10Z | In the header comment line |
| OSV | modified, published | RFC3339, UTC | Per the schema, ending in Z |
| OSV | modified_id.csv | 2026-10-19T04:00:18.69Z | ISO date, newest first |
The OSV schema defines modified as an RFC3339 timestamp in UTC ending in Z, and says that if two entries share an ID, the later modified time is authoritative.
Where mistakes happen
- Treating a bare date as midnight in your local zone. A date such as 2026-10-16 is a calendar day, so keep it as a date.
- Comparing a UTC timestamp to a local one. A release at 17:15 UTC is the next day in some zones.
- Parsing fractional seconds inconsistently. KEV shows four digits after the decimal and OSV can show more. Use a library that handles both.
- Calling a date range "inclusive" without saying so. Say whether the day you added an entry counts.
- Computing age as a difference of timestamps in one dataset and dates in another.
Steps for a clean analysis
- Parse timestamps as UTC and convert to a date only at the last step.
- Keep bare dates as dates, never as datetimes.
- When you subtract, say what unit you used: days between dates.
- State the weekday rule if you chart by weekday. See which weekdays CISA adds entries.
- Record the zone assumption in your methodology.
from datetime import date
added = date.fromisoformat("2026-10-16")
due = date.fromisoformat("2026-10-19")
print((due - added).days) # 3
Why it matters for time to exploit or fix
Any claim about "days from CVE to KEV" mixes a CVE publication timestamp and a KEV date. If one is UTC time and the other a bare date, a one day error can change a median or a share of "same day" cases. State the rule: "we compared UTC calendar dates". For one such analysis, see how old CVEs are when CISA adds them.
A worked example with a one day error
Take the KEV entry added on 2026-10-16 with a due date of 2026-10-19. The gap is three days when you subtract the bare dates. Across the catalog, the author found that the most common gap in the 2026.10.16 file was 21 days (1,025 entries), followed by 14 days (277) and 181 days (238), with 3 days for 139 entries. Those counts only make sense when both ends are dates.
Now suppose you compare dateAdded to the CVE's publication timestamp from a record that ends with Z. If you treat the date as midnight in a zone west of UTC and the timestamp as UTC, a flaw published late on 15 October UTC could appear to be published after the KEV date, giving a negative age. The fix is to convert the publication timestamp to a UTC date and then subtract two dates.
Rules for subtraction
| You have | You want | Do this |
|---|---|---|
| Date and date | Days between | Subtract directly |
| Timestamp and date | Days between | Convert the timestamp to a UTC date first |
| Timestamp and timestamp | Hours or days | Subtract in UTC, then state the unit |
| Local time from a log | Comparison with datasets | Convert to UTC before anything else |
State the rule in the methodology: "ages are differences between UTC calendar dates".
Weekday and cadence charts
If you chart additions by weekday, a bare date has no time zone, so the weekday is the calendar weekday of that date. A timestamp has to be converted to a UTC date before you assign a weekday. If you convert to a local zone for some rows and not others, the chart will mix definitions. For a weekday analysis of KEV, see which weekdays CISA adds entries.
EPSS dates
The EPSS header gives a score date with a time. When you say "scores from 18 October", you mean that timestamp. If you want a series, take one file per day and note each one's time. Days are not necessarily evenly spaced in time, though the file is described as published daily. FIRST describes a probability and percentile published every day for every CVE.
OSV dates
OSV timestamps carry UTC and can include more digits after the decimal point than KEV. Use a parser that accepts both. The modified time of a record is the key to freshness, and if two entries share an ID, the later modified time is authoritative per the schema. When you count records changed in a window, define the window as UTC timestamps, for example from midnight to midnight UTC.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the timing of a new disclosure drives what you do first.
Quick check
Should I convert KEV dateAdded to my local time zone?
No. It has no time component. Treat it as a calendar date.
What does the trailing Z mean?
It marks a UTC timestamp, also called Zulu time.
What if my data has a local time and I do not know the zone?
Do not guess. Mark the field as ambiguous, report how many rows are affected and avoid computing sub day differences.
Sources
- CISA KEV JSON feed, catalogVersion 2026.10.16, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (fetched 19 October 2026).
- EPSS daily scores file header, https://epss.empiricalsecurity.com/epss_scores-current.csv.gz (fetched 19 October 2026).
- OpenSSF OSV schema, https://ossf.github.io/osv-schema/ (fetched 19 October 2026).
- OSV data documentation, https://google.github.io/osv.dev/data/ (fetched 19 October 2026).
Last reviewed: 19 October 2026.
