SnowDriven Research · Methodology
How we verify every date.
Every date in the library comes from the vendor’s own lifecycle page, is cross-checked with endoflife.date, and carries the day it was last verified. SnowDriven, a software engineering studio in Pittsburgh, PA, maintains it.
- Covers
- 14 dates
- Sources
- Vendor pages
- Cross-check
- endoflife.date
- Re-check
- Aim: weekly
- Verified
- 7–20 Oct 2026
- Source
- The vendor’s own lifecycle page for every date: Microsoft Learn and the .NET support policy, and php.net.
- Cross-check
- endoflife.date, an open, community-maintained reference. Where it differs, the vendor’s page decides.
- Date
- The last supported day, as a US calendar day. It counts as ended from the next day, New York time.
- Verified
- Each row shows the day it was last checked against its source. We never change a date to look fresh.
- Corrections
- Logged with their date in the changelog. Report a problem by email.
How a date is verified
From the vendor, with the day recorded. Five steps for every row.
Read the vendor’s page
The product’s lifecycle page on Microsoft Learn, Microsoft’s .NET support policy, or php.net’s supported-versions and end-of-life pages. Never a news story, a blog or a reseller.
Record the last supported day
Microsoft lists an end as an early-morning UTC time on the following day, the end of the day in Redmond; we record that US calendar day, as endoflife.date does. php.net gives the day itself.
Cross-check
Compare the date with endoflife.date. If they disagree, we read the vendor’s page again: the vendor’s date is the one we publish.
Date the check
Write down the day the row was verified. It appears beside the row, in the data files and in the calendar.
Publish from one table
The deadline table, the JSON and CSV files, the calendar, the guides and this site’s search are all generated from the same table, so they can’t disagree.
The library covers .NET, .NET Framework, PHP, Windows Server and SQL Server: the platforms we modernize. Sources in use today:
When a deadline counts as ended
On the day after the last supported day, by New York’s calendar.
Vendors publish the last day something is supported, so on the date itself a deadline is still ahead. From the next calendar day in New York (America/New_York) it counts as ended. One rule decides it everywhere: the guides, the deadline table, the data files and this site’s search.
The pages are built ahead of time, so the “ended” wording goes live with the first deploy on or after that day. Until then, the day count beside each date is worked out in your browser from your own clock, and it says “Ended” as soon as the date has passed.
A date’s status is one of three, always written out and marked with a shape as well as a colour: Upcoming, Ending soon (within 120 days) and Ended.
What each milestone means
“End of support” means different things for different products. Each row says which one it is.
- End of support
- The vendor stops releasing updates, security fixes included.
- End of security support
- The project stops releasing security fixes for this branch.
- End of extended support
- Microsoft’s security updates under extended support stop.
- End of Extended Security Updates
- The last security updates Microsoft offers for this version stop.
- End of mainstream support
- No new features or non-security fixes; security updates continue until extended support ends.
How often we re-check
We aim for every week, and always before a deadline.
We aim to re-check every row each week, and always in the week before a deadline, against its primary source and the cross-check. When a vendor moves a date we update the row, its verified day and anything generated from it, and log the change. A row’s verified day moves only when it was actually checked; an unchanged page keeps its “Updated” date.
We add deadlines as we verify them, and always once one is within about four months, verified the same way.
Every change is listed with its date in the changelog.
Corrections
If a date looks wrong, tell us. No form, no account.
How to report it
Use “Report a problem” at the foot of any research page, or email hello@snowdriven.com. Name the row (each has a link, such as #net-8) and, if you can, the source that shows the right date.
What happens next
We check the report against the vendor’s page. If the table is wrong, we correct the row and its verified day, log the correction with its date in the changelog, and the data files, calendar and guides follow on the next deploy. Corrections are never made silently.
The WordPress PHP data
A daily record of public figures, with its limits stated.
What it is
- Once a day, about 07:17 UTC, we save WordPress.org PHP version statistics exactly as published: the share of WordPress installs on each PHP version.
- One snapshot per UTC day, from the first day one was stored. WordPress.org publishes only the current figures, so there is no earlier history to collect.
- Beside each day, the share on PHP versions the PHP project no longer patches that day and the share on PHP 8.2, using php.net’s dates.
- Published on the end-of-life PHP tracker and as JSON and CSV, with the missing days listed.
What it isn’t
- Not every website, and not every WordPress site: only installs that report their PHP version to WordPress.org when they check for updates.
- Not a sample we designed. WordPress.org doesn’t document how it samples or rounds, and publishes no site count, so the figures are shares, not numbers of sites.
- Never filled in. A day whose fetch failed or looked wrong is a gap, listed as one; nothing is copied forward or estimated.
- Not a measure of patching. Some hosts and Linux distributions backport security fixes to older PHP versions; WordPress.org’s figures can’t show which sites have that, so the shares measure support from the PHP project only.
- Not a forecast or a risk score.
What we don’t publish
What’s missing is missing on purpose.
- No risk scores, vulnerability counts or estimates of what staying on an old version costs.
- No date we haven’t read on the vendor’s own page. Where we haven’t verified what to move to, the table sends you to the vendor rather than guess.
- No figures about our clients. When we publish first-party findings, they will say how many systems they cover and how they were gathered.
The data files are free to read and download, with no account. The dataset page describes every field and the reuse terms; the files themselves are at JSON, CSV and ICS.
About this page
Cite this page
SnowDriven. “How we verify every date.” SnowDriven Research. https://snowdriven.com/research/methodology/ (last updated 13 October 2026).
One click or tap selects the whole citation, ready to copy.
About these dates
Each date is the vendor’s own, copied from its lifecycle page and checked on the day shown. Vendors can move dates without notice, and our copy can fall behind or contain mistakes, so confirm with the vendor before you rely on a date for a decision, contract or compliance deadline. Information only, provided as is (terms). Reuse: free to download and quote, with credit to SnowDriven and a link (terms of use).
Start a project
The same care, applied to your system.
A modernization audit checks every runtime, framework and dependency you run against its vendor’s dates, ranks the risks in plain language and plans the move in stages.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call