Holding an order, and when it comes back

Three ways to say how long

A quick set is one press: five, ten, fifteen, thirty or sixty minutes. Those are the intervals a kitchen says out loud, and the list is deliberately short — a longer menu becomes a scroll, which is the opposite of a quick set.

A custom timer takes hours and minutes from now. Ninety typed into the minutes field is accepted as ninety minutes rather than rejected for being more than sixty, because somebody typing into a minutes field should not be argued with.

An exact time holds until a specific moment, which is what a catering order due at five o'clock actually needs.

What the app refuses

A negative hold is refused. So is a zero-length one: that is a release, and releasing is asked for differently rather than expressed as a hold of no length.

A hold longer than twenty-four hours is refused as a mistyped field. A ticket held past the end of a shift is a typing mistake, not an instruction, and the moment to catch it is while somebody is still standing there.

One instant, however you said it

All three ways collapse into a single moment the ticket comes back, and they do it before anything durable is written. Keeping which method was used alongside the instant would put two records of the same fact in the log, and they drift the first time a clock moves under a running hold.

A relative hold is measured from the instant the cook pressed it, not from a clock read a moment afterwards. An exact time is passed through untouched rather than recalculated, and it is kept as a moment in UTC — so a hold set before the clocks change releases at the time that was chosen, not an hour either side of it.

Where this came from

Every statement above was read out of the source code named below, and the build re-reads those files and fails if a statement stops matching them. This article carries no claim that was not measured from one of these files.

• android/app/src/main/kotlin/online/minirestaurants/kds/interaction/HoldRequest.kt