Due dates and times

From words to a timestamp#

The parse runs on the words that were actually said, which is why the guard on booking matters as much as the parser does: a when that shares no time word with the caller's latest time-bearing line is refused outright rather than parsed generously. Getting the time right starts with only ever parsing a time somebody said.

Which clock#

The due time lands in the line's timezone — the timezone of the phone line the conversation happened on — not the browser's, not the server's, and not the timezone of whoever happens to open the queue later. That is the only choice that makes "tomorrow 11am" mean what the caller meant, because the caller was talking to that line.

The consequence worth knowing: a colleague in a different timezone reading the same queue sees the same instant rendered in their own clock, and it will not read as 11am to them. That is correct. The row is a commitment to a person in a place, not an entry in your diary.

Why the fallback is 11:00 tomorrow#

Two obvious alternatives are worse. Falling back to *now* would make every unparsed promise immediately due, so the queue would fill with rows demanding action that nobody promised at that moment — and on the phone channel, some of them would be rung within the minute. Falling back to *never* would silently drop commitments, which is the failure the whole record exists to prevent.

11:00 the following day is a working hour in the line's own timezone, far enough away that a person can correct it before it fires, and close enough that nothing waits a week. It is a deliberate default, and a queue with several rows at 11:00 tomorrow is a signal: those are the promises where nobody named a time.

Due is a permission, not an appointment#

• A drain acts on a tick, so a row becomes due and is then picked up on the next pass rather than at the exact second.
• The phone drain takes two rows per tick, so a queue of ten call-backs all due at once is worked through over several ticks rather than dialling ten lines at the same moment.
• A gate can hold a due row without delaying it: a line that is not ready is retried in an hour, and the row keeps its original due time as the record of what was promised.
• A row that goes more than 24 hours past due on the phone channel is closed rather than rung — see A follow-up that is too late.

What goes wrong with times#

The time is a day out

A weekday said on that same weekday resolves forward. "Friday" spoken on Friday is next Friday, which is usually what the caller meant and occasionally not.

Everything is at 11:00

Nobody is naming times. That is a conversation problem rather than a parser problem: the fix is asking for a time, which the voice does when the caller has neither named nor agreed one.

It fired later than the due time

Expected. The due time authorises the action; ticks, the two-per-tick phone limit and any gate decide the moment.

It never fired

Check lateness first, then the gate. A closed row that reads missed: was past the 24-hour cut-off; a row still open with a refusal against it was gated.

Questions#

Related#

• Follow-ups in Connect
• Creating a follow-up
• A follow-up that is too late
• Overdue follow-ups
• The follow-up went out at the wrong time
• A time is shown in the wrong zone