27
3
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
2I just can't find the left-pad built-in ... – a'_' – 2020-02-25T14:40:13.817
Related (the portion about verifying whether a 6-digit number is a valid time) – Kevin Cruijssen – 2020-02-25T15:04:55.307
5You say input is
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). – Grimmy – 2020-02-25T15:05:23.843@Grimmy if your program accepts inputs outside of the range
0..235959
they should be falsy, but the specification doesn't require your program to be able to deal with inputs outside of that range – simonalexander2005 – 2020-02-25T15:11:11.8039It's probably too late now, but I think this challenge would be more fun if the range could be beyond the
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. – Kevin Cruijssen – 2020-02-25T16:42:10.247Strictly speaking
as long as it can be documented how to tell what is True and what is not
means we can no-op. I believe you really want outputs to be in one of these four pairs: truthy vs falsey; falsey vs truthy; unique value, x vs anything but x; anything but x vs unique value x. – Jonathan Allan – 2020-02-25T18:40:58.9502This is assuming a day with no leap second, or possibly TAI. For example, 2016-12-31 18:59:60 US/Eastern is a valid time. – aschepler – 2020-02-26T06:37:05.627