Introduction:
Some times using a 24-hour clock are formatted in a nice pattern. For these patterns, we'll have four different categories:
All the same (pattern A:AA or AA:AA):
0:00
1:11
2:22
3:33
4:44
5:55
11:11
22:22
Increasing (pattern B:CD or AB:CD, where D==C+1==B+2==A+3):
0:12
1:23
2:34
3:45
4:56
12:34
23:45
Pair (pattern AB:AB):
10:10
12:12
13:13
14:14
15:15
16:16
17:17
18:18
19:19
20:20
21:21
23:23
Palindrome (pattern A:BA or AB:BA):
0:10
0:20
0:30
0:40
0:50
1:01
1:21
1:31
1:41
1:51
2:02
2:12
2:32
2:42
2:52
3:03
3:13
3:23
3:43
3:53
4:04
4:14
4:24
4:34
4:54
5:05
5:15
5:25
5:35
5:45
6:06
6:16
6:26
6:36
6:46
6:56
7:07
7:17
7:27
7:37
7:47
7:57
8:08
8:18
8:28
8:38
8:48
8:58
9:09
9:19
9:29
9:39
9:49
9:59
10:01
12:21
13:31
14:41
15:51
20:02
21:12
23:32
Challenge:
Given a starting time and a category, output how many minutes should be added to the start time, for it to reach the closest (forward) time of the given category.
For example: if the start time is 14:47
and the category is palindrome
, the smallest time after 14:47
in the palindrome category is 15:51
, so the output is 64
minutes (because 14:47 + 64 minutes = 15:51).
Challenge Rules:
- As you may have noted: the times in the 'All the same' category are excluded from the 'Pair' and 'Palindrome' categories, even though they are technically also pairs/palindromes.
- We only look forward when we go to the closest time. So in the example above the output is
64
(time15:51
) and not-6
(time14:41
). - You may take the times in any reasonable format. May be a string, a (Date)Time-object, a pair of integers, etc.
- You may use any reasonable distinct input-values for the four categories. (Keep in mind this forbidden loophole!) May be four integers; may be the category-names as strings; may be an enum; etc.
- If the input-time is already valid for the given category, the result is
0
(so we won't look for the next one). - We use an
A:BC
pattern for single-digit hours, so they won't be left-padded with a0
to0A:BC
.
General Rules:
- This is code-golf, so the shortest answer in bytes wins.
Don't let code-golf languages discourage you from posting answers with non-codegolfing languages. Try to come up with an as short as possible answer for 'any' programming language. - Standard rules apply for your answer with default I/O rules, so you are allowed to use STDIN/STDOUT, functions/method with the proper parameters and return-type, full programs. Your call.
- Default Loopholes are forbidden.
- If possible, please add a link with a test for your code (e.g. TIO).
- Also, adding an explanation for your answer is highly recommended.
Test Cases:
You don't need to output the time between parenthesis. Those are just added as clarification in the test cases below. Only the integer-output is required to be output.
Inputs: 14:47, palindrome
Output: 64 (15:51)
Inputs: 0:00, all the same
Output: 0 (0:00)
Inputs: 23:33, palindrome
Output: 37 (0:10)
Inputs: 23:24, pair
Output: 646 (10:10)
Inputs: 10:00, increasing
Output: 154 (12:34)
Inputs: 0:00, increasing
Output: 12 (0:12)
Inputs: 23:59, all the same
Output: 1 (0:00)
Inputs: 11:11, pair
Output: 61 (12:12)
A:BC
pattern for single-digit hours, so they won't be left-padded with a0
to0A:BC
.". Does this mean the input, as numbers, has to be[0,1,2,3]
or[1,2,3]
for a time of"1:23"
as a string? Or I'm mixing stuff up? \$\endgroup\$[hours,minutes]
(or two loosehours
andminutes
inputs) - e.g.[1,23]
instead of1:23
. Although I guess[1,2,3]
instead of1:23
is valid as well if you want. \$\endgroup\$23:59
. Does it output0:00
(1) for "all the same" and0:10
(11) for "palindrome"? Or it isn't supposed to wrap around? \$\endgroup\$11:11, pair ~> 61
. \$\endgroup\$