Watch 9 video solutions for Minimum Number of Operations to Convert Time, a easy level problem involving String, Greedy. This walkthrough by Bro Coders has 1,139 views views. Want to try solving it yourself? Practice on FleetCode or read the detailed text solution.
You are given two strings current and correct representing two 24-hour times.
24-hour times are formatted as "HH:MM", where HH is between 00 and 23, and MM is between 00 and 59. The earliest 24-hour time is 00:00, and the latest is 23:59.
In one operation you can increase the time current by 1, 5, 15, or 60 minutes. You can perform this operation any number of times.
Return the minimum number of operations needed to convert current to correct.
Example 1:
Input: current = "02:30", correct = "04:35" Output: 3 Explanation: We can convert current to correct in 3 operations as follows: - Add 60 minutes to current. current becomes "03:30". - Add 60 minutes to current. current becomes "04:30". - Add 5 minutes to current. current becomes "04:35". It can be proven that it is not possible to convert current to correct in fewer than 3 operations.
Example 2:
Input: current = "11:00", correct = "11:01" Output: 1 Explanation: We only have to add one minute to current, so the minimum number of operations needed is 1.
Constraints:
current and correct are in the format "HH:MM"current <= correctProblem Overview: You are given two time strings current and correct in HH:MM format. In one operation you can add 1, 5, 15, or 60 minutes to the current time. The goal is to reach the correct time using the minimum number of operations.
Approach 1: Greedy with Minutes Conversion (Time: O(1), Space: O(1))
Convert both times into total minutes from midnight. Compute the difference diff = correctMinutes - currentMinutes. The allowed operations are fixed increments: 60, 15, 5, and 1. Apply a greedy strategy by repeatedly taking the largest possible increment that does not exceed the remaining difference. For example, use as many 60-minute operations as possible, then 15, then 5, and finally 1. Because these increments form a canonical system, the greedy choice always produces the minimum number of operations. The computation involves a few integer divisions and remainders, so runtime is constant.
The key insight: minimizing operations is equivalent to minimizing the number of increments used to build the minute difference. With fixed step sizes, greedy selection works the same way as making change with standard coin denominations. You simply reduce the remaining minutes with the largest step first.
Relevant concepts appear frequently in greedy algorithms and basic string parsing problems.
Approach 2: Dynamic Programming (Time: O(D * 4), Space: O(D))
Dynamic programming treats the problem like a small coin change variant. Let D be the minute difference. Build a DP array where dp[i] represents the minimum operations needed to reach exactly i minutes. For each minute value, check transitions using the allowed operations {1, 5, 15, 60}. The recurrence is dp[i] = 1 + min(dp[i - step]) for valid steps.
This guarantees an optimal answer for every intermediate value and works even if the operation set changes. However, it requires iterating through all minute values up to D, so it is slower and uses extra memory. For this problem the difference is at most 1439 minutes, so it still runs fast in practice. This approach connects to classic dynamic programming patterns used in coin change problems.
Recommended for interviews: The greedy minutes-conversion approach is what interviewers expect. It shows you recognized the fixed increments and reduced the problem to a simple arithmetic strategy. The DP method demonstrates problem generalization, but greedy is the clean, optimal solution with constant time and space.
| Approach | Time | Space | When to Use |
|---|---|---|---|
| Greedy with Minutes Conversion | O(1) | O(1) | Best choice when operation increments are fixed (60,15,5,1). Minimal logic and constant runtime. |
| Dynamic Programming (Coin Change Style) | O(D * 4) | O(D) | Useful when increment values are arbitrary or greedy optimality is not guaranteed. |