Go-dark dates, the renewal ladder, and the last safe day to ship a bridge release. Windows Authenticode. All arithmetic, no network.
This is the arithmetic half of windows-code-signing-and-smartscreen-reference, which is the prose half: that repo explains what Authenticode, timestamping and SmartScreen reputation actually do, and this page does the date maths those rules imply. It is not a generic date subtractor. The catalog already has duration-calculator for subtracting two dates; this page encodes three specific signing rules on top of the subtraction, quoted and sourced below.
The issue date decides which cap applies. The tool checks your notAfter against that cap and computes the cycle length in days rather than quoting a day count from memory.
Uptake per cycle is your input, not a published figure. Nothing on this page supplies an industry adoption rate, because there is no verifiable one to supply. Put your own telemetry in, or run the number twice at a pessimistic and an optimistic rate and take the earlier date.
Replace these placeholder rows with your own build output. Nothing is uploaded; the parse runs in this tab.
The ladder is computed from whatever start date you type. Change the start date and every row changes with it.
"Always time-stamp your Authenticode signatures. Without a time stamp, the signature becomes invalid when the signing certificate expires, and Windows will treat the binary as unsigned. Time stamping ensures long-term signature validity."
Microsoft, "Time Stamping Authenticode Signatures". https://learn.microsoft.com/en-us/windows/win32/seccrypto/time-stamping-authenticode-signatures
"Time stamping allows Authenticode signatures to be verifiable even after the certificates used for signature have expired."
"The countersignature method of time stamping implemented below allows for signatures to be verified even after the signing certificate has expired or been revoked."
Microsoft, same page. The second sentence covers revocation as well as expiry.
The part worth stating precisely, in my own words rather than Microsoft's: signature validation happens at verify time, on the machine doing the verifying, not at download time. A copy that already sits on a user's disk or on a mirror is re-checked when it is next opened, so it starts failing on the same day a fresh download does. Nothing has to be re-published for that to happen. That is the mechanism, and it is why a go-dark date is a date rather than a rollout.
"For Code Signing Certificates issued before March 1st, 2026, the validity period MUST NOT exceed 39 months. For Code Signing Certificates issued on or after March 1st, 2026, the validity period MUST NOT exceed 460 days."
CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates, section 6.3.2. https://github.com/cabforum/code-signing/blob/main/docs/CSBR.md and https://cabforum.org/working-groups/code-signing/requirements/
39 months is a calendar span, not a fixed number of days, so the tool adds 39 months to your notBefore with month-end clamping and reports the resulting day count for your dates. It does not print a constant, because the constant depends on which months you cross. 460 days is a fixed count and is applied as one. Because 460 days is longer than a year, each renewal under the new cap falls later in the calendar than the previous one, not earlier, and the ladder above shows exactly how much later for your dates.
electron-updater checks a downloaded installer against the publisherName list that was compiled into the build the user already has. A build that only knows the old publisher name will refuse an installer signed with a new certificate whose subject differs. The fix is a bridge release that carries both the old and the new publisher name, signed while the old certificate is still valid, and it only helps the users who actually install it. So the real deadline is the last day you can ship that bridge and still have your target share of the installed base carrying it before the old certificate stops signing. The tool works backwards from notAfter using your cadence and your own uptake assumption, and prints the working.