A time in the format hhMMss is represented by six numbers in the range 0..9 (e.g.100203
for 3 seconds after 2 minutes after 10am (10:02.03), or 155603
for three seconds after 56 minutes after 3pm (15:56.03).
Treating these times as integers, these numbers are therefore in the range 000000
to 235959
; but not all numbers in that range are valid times.
Normally, though, integers aren't represented with leading 0s, right?
So, this challenge is to take a numeric input (without leading 0s), and say whether it represents a proper time or not when the leading 0s are put back.
Input
Any integer, as a string or an integer type, in the range 0..235959
inclusive. all numbers as strings will be input with no leading 0s (e.g. 2400
, not 002400
). The time 000000
maps to 0
; or exceptionally as
. Inputs outside of this range should return Falsy, but there is no requirement that they are supported.
Output
Truthy/Falsy value - by which I mean there must be a consistent distinction in the output between True and False - e.g. True could be output as 1
and False could be any other output (or even a variable output) - as long as it can be documented how to tell what is True and what is not.
More Challenge Details
Given the input integer, figure out if the number represents a time (Truthy) or not (Falsy).
A number represents a time if a time (hhMMss) with leading 0s removed is the same as the number.
e.g. 00:00.24 is represented by 24
e.g. 00:06.51 is represented by 651
e.g. 00:16.06 is represented by 1606
e.g. 05:24.00 is represented by 52400
e.g. 17:25.33 is represented by 172533
There are therefore some numbers that can't represent times:
e.g. 7520 - this can't represent hhMMss because 00:75:20 isn't a time
As a general rule, the valid numbers fall into the pattern:
trimLeadingZeros([00..23][00..59][00..59]);
The following numbers are the entire set of inputs and the required answers for this challenge
Seconds only (e.g. 00:00.ss, with punctuation and leading 0s removed, -> ss)
0 to 59
- Truthy
60 to 99
- Falsy
Minutes and seconds (e.g. 00:MM.ss, with punctuation and leading zeros removed, -> MMss)
100 to 159
- Truthy
160 to 199
- Falsy
etc, up to:
2300 to 2359
- Truthy
2360 to 2399
- Falsy
2400 to 2459
- Truthy
2460 to 2499
- Falsy
etc, up to:
5900 to 5959
- Truthy
5960 to 9999
- Falsy
Hours 0..9, minutes and seconds (e.g. 0h:MM.ss with punctuation and leading zeros removed -> hMMss)
10000 to 10059
- Truthy
10060 to 10099
- Falsy
etc, up to:
15800 to 15859
- Truthy
15860 to 15899
- Falsy
15900 to 15959
- Truthy
15960 to 19999
- Falsy
20000 to 20059
- Truthy
20060 to 20099
- Falsy
20100 to 20159
- Truthy
20160 to 20199
- Falsy
etc, up to:
25800 to 25859
- Truthy
25860 to 25899
- Falsy
25900 to 25959
- Truthy
25960 to 25999
- Falsy
etc, up to:
95800 to 95859
- Truthy
95860 to 95899
- Falsy
95900 to 95959
- Truthy
95960 to 99999
- Falsy
Hours 10..23, minutes and seconds (e.g. hh:MM.ss with punctuation and leading zeros removed -> hhMMss)
100000 to 100059
- Truthy
100060 to 100099
- Falsy
100100 to 100159
- Truthy
100160 to 100199
- Falsy
etc, up to:
105800 to 105859
- Truthy
105860 to 105899
- Falsy
105900 to 105959
- Truthy
105960 to 109999
- Falsy
This pattern is then repeated up to:
235900 to 235959
- Truthy
(236000 onwards
- Falsy, if supported by program)
Leading 0s must be truncated in the input, if strings are used.
Code golf, so least bytes wins - usual rules apply.
in the range 0..235959 inclusive
, but then you have a test case for236000 onwards
. You should clarify what's the actual range of inputs we need to support (I'd suggest 0..999999). \$\endgroup\$235959
and possibly even beyond the999999
. Now it simply boils down to (in pseudo-code)max(hh,mm,ss)<60
and we can just ignore the check on hours, since it's guaranteed to be valid. \$\endgroup\$