Yesterday, as part of a IQ-style test, I got this interesting question:
The time on a 24-hour clock is 11:43. What is the least number of minutes I should wait before the same digits are on the screen again (in any valid 24-hour time order)?
The answer's 91 minutes, if you were wondering!
This stuck in my mind, and it finds its way... here. In an adapted form, however... Your task is, given a 24-hour time string in the format HH:MM
(or in any other way as long as it provides HH
and MM
), shift the digits around until you find 24-hour time strings that would be in the same day counting forwards, and pick the one whose distance to the input is the shortest. Then return the number of minutes to the picked time string as an integer, using default output rules.
Method:
See above.
Input:
Allow facilities for input such that 2 digits of hours and 2 digits of minutes are provided. Do not worry about invalid input (example: 25:12
, 1:34
[01:34
will be correct, however], and 05:89
).
You cannot use 12-hour system.
Output:
An integer. Note that it should be in minutes, not seconds or any other unit (this is fixed)
Return a distinct value (like 1440, an error, etc. I'm using "Nil" in the test-cases) when no valid shifted 24-hour time string can be created until 23:59.
Test cases:
Input (HH:MM) -> Output (Int or "Nil")
11:43 -> 91
01:01 -> 9
17:38 -> 59
14:21 -> 413
13:20 -> 413
23:41 -> Nil
00:00 -> Nil
Scoring:
This is code-golf, so shortest answer wins!
21:14
can't come from14:21
\$\endgroup\$f(hours,minutes)
or it must be a stringf('hh:mm')
? \$\endgroup\$03
does not get parsed as3
. \$\endgroup\$03
. You can writef(03,08)
but it will be the same asf(3,8)
but it doesn't affect to the algorithm or result. Passing numbers instead of string(s) just allow me to not usesplit
method and/or not convert strings to numbers so it saves me some bytes \$\endgroup\$00:00 -> Nil
\$\endgroup\$