# When does hh:mm = mm.ss?

## Raku, ~~14 12~~ 11 bytes

```
0+|*/.98334
```

Try it online!

Since we know the bounds of the input, we can substitute a constant operation and a floor on the input in base 60. That number by the way is around `1358/1381`

, which is the maximum the input differs from the output in base 60. There may be a smaller constant, or at least a smaller way to represent it. For reference, the shortest constant you can multiply by, rather than divide, is `1.01694`

.

## Python 3.8, ~~40~~ 36 bytes

```
lambda h,m:(d:=h+(h+m)//60,(d+m)%60)
```

Try it online!

## R, 42 bytes

```
function(h,m)c(t<-(h*60+m)/59,60*t%%1)%/%1
```

Try it online!

Version 2: -3 bytes thanks to clarification that we don't need to output the **first** match when the timer & clock show the same numbers.

So this version outputs the second match for an input of `0:59`

(in other words, `1:00`

instead of the first match at `0:59`

), and similarly for all other outputs that can end with `:59`

or `:00`

.

## R, Version 1: ~~49~~ 45 bytes

```
function(h,m)c(t<-(h+m/60)*6/5.9,60*t%%1)%/%1
```

Try it online!

Outputs the **first** timer-clock match (so, always a match ending `0:59`

instead of a subsequent match ending `:00`

).

This exploits the floating-point rounding of `*6/5.9`

to slightly less than `*60/59`

, but using the same number of characters. This effectively gives us a floor-like result that rounds-down exact integers in the output (the desired behaviour). Using `*60/59`

gives an exact floating-point result and so doesn't do this.

~~(Frustratingly, though, it still isn't as short as simply porting ovs's approach for 43 bytes).~~ Version 2 (above) is shorter.