BatteryInfoView shows four time estimates, and they are among its most useful — and most misread — numbers. Useful, because ‘about two hours at the current pace’ is the form in which battery information actually drives decisions. Misread, because the word ‘Estimated’ in every one of their names is doing real work: these are not timers, not promises, and not measurements of the future. NirSoft documents exactly how they are calculated, and once you know the method, their behaviour — including the famous swings — stops looking like a bug. Follow along with the tool from the download page (official NirSoft file via /go/batteryinfoview), and see the Battery Health hub for the surrounding topics.
The four fields
Fields 16 to 19 of the official field list are the estimates, and each answers a distinct question:
- Field 16 — Remaining battery time for the current activity (Estimated): at the current pace, how long the charge you have now will last.
- Field 17 — Full battery time for the current activity (Estimated): at the current pace, how long a full charge would last — the runtime figure for your battery in its current condition, under the current kind of activity.
- Field 18 — Remaining time for charging the battery (Estimated): at the current charging pace, how long until the battery is full.
- Field 19 — Total time for charging the battery (Estimated): the total charge duration at that pace — and this one is documented as shown only while charging.
Note the phrase ‘for the current activity’ baked into fields 16 and 17. The estimates are explicitly scoped to what the machine is doing now, not to some average of your day and not to a manufacturer’s laboratory workload. Field 17 deserves special attention from health-watchers: it combines your battery’s present Full Charged Capacity with your present consumption, so it expresses wear in the unit you actually care about — time. A battery can hold 80% of its design capacity (see Battery Health % Explained) and field 17 translates that 80% into the runtime you will really experience under your real workload.
The documented calculation: the last 30 seconds
All four estimates share one documented basis: they are calculated from the change in Current Capacity Value over the last 30 seconds. The program watches how much stored energy — the Current Capacity Value, usually in mWh — was gained or lost during the most recent half-minute, turns that into a rate, and projects the relevant total at that rate. Remaining time is, in essence, current charge divided by recent drain; remaining charge time is the mirror image while charging.
Two operational details follow from the method. First, the estimates need a window of real behaviour before they mean anything: a reading in the first seconds after opening the program, or immediately after a big workload change, is a projection from almost no evidence. Second, these calculated fields update only every 30 seconds or more, even though the Battery Information view as a whole refreshes every 10 seconds by default — the cadence matches the size of the window they are calculated over. The close relationship with field 12 is worth seeing too: the estimates are the projection, the Charge/Discharge Rate is the underlying movement they are projected from.
Why the estimates swing — and why that is honest
A 30-second window is short, and laptop workloads are spiky. Start a video call, a compile, a game or a large sync and the last 30 seconds suddenly contain heavy drain; the remaining-time estimate contracts accordingly, sometimes dramatically. Close everything and let the machine idle and the same arithmetic stretches the estimate out. Neither reading is lying: each is a faithful projection of the pace in its window. The estimate answers ‘if the last 30 seconds continued indefinitely, when would we run out?’ — and since the last 30 seconds rarely do continue indefinitely, the answer keeps changing.
- Judge the estimate by steady work: let a representative workload run for several minutes, then read the estimate. It will be far more stable — and far more meaningful — than one caught during a transition.
- Expect movement at plug and unplug: the window straddling a power-state change mixes two different regimes, and the projection needs a fresh window to settle.
- Compare estimates only under comparable activity: field 17 read during idle and field 17 read during gaming are answers about two different activities, not evidence that the battery changed.
The charging-only field, and charging estimates generally
Field 19, Total time for charging the battery (Estimated), is documented as appearing only while charging — if you cannot find it while running on battery, nothing is wrong; it has nothing to describe in that state. Fields 18 and 19 are projections from the recent charging pace by the same 30-second method, so they inherit the same behaviour: a charging rate that varies — as it commonly does across a charge, and as it will if you keep working the machine hard while it charges — will move both estimates. For the live rate behind them, watch the Charge/Discharge Rate field while plugged in; its sign and size, read next to the Power State, tell you whether the charger is comfortably ahead of your workload or barely keeping pace.
Using estimates well
Treat the four fields as pace indicators, not appointments. Their best uses are comparative and immediate: deciding whether the current charge plausibly covers the next meeting at the current pace, noticing that today’s pace is far hungrier than yesterday’s for the same work, or checking whether a change you just made — a closed program, a different workload — actually extended the projection in the log. For the comparative use across a whole session, the Battery Log (F8) records status every 30 seconds by default, and a saved log (see the Battery Log guide and How to Export a Battery Report) lets you see the estimates evolve alongside the percentages that produced them.
What the estimates can never do is certify a future outcome, and neither NirSoft nor this site presents them as doing so. They are labelled estimates, calculated by a documented method, from a deliberately recent window. Understood that way, they are one of the most honest features in the program. The rest of the field-by-field coverage lives in the Battery Health hub.
Frequently asked questions
Why does my remaining time drop by an hour when I open a program?
Because the estimate is recalculated from the last 30 seconds of capacity change. A heavy 30 seconds projects a short remaining time; as steadier behaviour fills the window, the estimate recovers. The battery lost no extra health in the process.
Why is the Total time for charging field missing?
Field 19 is documented as shown only while charging. On battery power there is no charging total to estimate, so the field is absent by design.
Which estimate should I watch on a long flight?
Field 16 — remaining time for the current activity — read after your in-flight workload (offline reading, video, writing) has been running steadily for a few minutes, and re-checked occasionally rather than continuously.