Last Updated: April 1, 2026
We have a list of daily temperatures and, for each day, we need to figure out how many days until a strictly warmer temperature occurs. If no warmer day exists in the future, the answer for that day is 0.
The brute force instinct is obvious: for each day, scan forward until you find something warmer. But notice that many days might share the same "next warmer day." For instance, if temperatures drop for several days and then spike, that spike resolves multiple days at once. This batching behavior is the key insight, and it points directly at a stack-based approach where we accumulate unresolved days and pop them off when a warmer day arrives.
1 <= temperatures.length <= 10^5 -- With up to 100,000 elements, an O(n^2) brute force would hit 10^10 operations in the worst case. We need O(n) or O(n log n).30 <= temperatures[i] <= 100 -- Temperatures live in a narrow range of only 71 distinct values. This opens the door to counting-based optimizations, though O(n) stack approaches are simpler.The simplest approach is exactly what the problem describes: for each day, look at every future day until you find one that is warmer. If you find it, record the distance. If you reach the end without finding one, the answer is 0.
This works correctly but does a lot of repeated scanning. If the temperatures are decreasing for a long stretch followed by a spike, every day in that stretch scans all the way to the spike independently.
i from 0 to n-1:j from i+1 to n-1:temperatures[j] > temperatures[i], set answer[i] = j - i and break.This approach works but is too slow for the constraint of n up to 10^5. Many days end up scanning to the same warmer day independently. What if we accumulated unresolved days and resolved them all at once when a warmer day appears?
Instead of having each day search forward for its answer, flip the perspective: process days left to right and maintain a stack of days that have not yet found a warmer future day. The stack holds indices, and the temperatures at those indices are in decreasing order (a monotonic decreasing stack).
When we arrive at a new day, we check: is today's temperature warmer than the temperature at the index on top of the stack? If so, today is the answer for that stacked day. We pop it off and record the distance. We keep popping as long as today is warmer than the stack's top, because today resolves all of those cooler days. Then we push today onto the stack.
The beauty of this approach is that each index is pushed once and popped once, so the total work across all days is O(n), even though the inner while loop might pop multiple elements on some iterations.
The stack maintains the invariant that temperatures at stacked indices are in decreasing order from bottom to top. If a new day were warmer than the top, we would have popped the top before pushing. This means the stack is always a "monotonic decreasing stack."
When a warmer day arrives, it resolves every cooler day on top of the stack in one burst. Each index enters the stack exactly once and leaves exactly once, so across all iterations, the total number of push and pop operations is at most 2n. That is why the algorithm is O(n) despite having a while loop inside a for loop.
i from 0 to n-1:temperatures[i] > temperatures[stack.top]:prevDay from the stack.answer[prevDay] = i - prevDay.i onto the stack.The monotonic stack is already O(n) in time, which is optimal. But it uses O(n) extra space for the stack. What if we processed from right to left and used the answer array itself to skip ahead, eliminating the stack entirely?
Here is a clever observation: if we process days from right to left, and we have already computed the answer for future days, we can use those answers as "jump pointers" to skip ahead.
For day i, we check day i+1. If it is warmer, great, the answer is 1. If not, we know that answer[i+1] tells us the next warmer day after i+1. So we jump to i + 1 + answer[i+1] and check that day. We keep jumping until we either find a warmer day or land on a day with answer = 0 (meaning no warmer day exists from that point forward).
This eliminates the need for a stack entirely. We use the answer array itself as our navigation structure.
The key insight is that the answer array creates a linked-list-like structure. If day j has answer[j] = k, it means the next warmer day after j is at j + k. So when we are looking for a warmer day after i, and day j is not warm enough, we can jump directly to the next warmer day after j rather than checking every day in between.
This works because if temperatures[j] <= temperatures[i], then any day between j and j + answer[j] also has a temperature no greater than temperatures[j] (otherwise, answer[j] would point to that closer day instead). Since those intermediate days are all at most as warm as j, and j is not warm enough for i, none of them can be warm enough for i either. So skipping them is safe.
n-2 down to 0 (the last day's answer is always 0):j = i + 1.temperatures[j] <= temperatures[i]:answer[j] == 0, no warmer day exists from j onward, so answer[i] = 0. Break.j = j + answer[j].temperatures[j] > temperatures[i], set answer[i] = j - i.