Log work often lands on second boundaries even when the UI rounds. You have the error at 9:30:00 and need when the request started if the hop was forty-five seconds. A video editor marks a cut and wants the frame anchor one hundred twenty seconds earlier. Metrics export a spike time and someone says "pull thirty seconds before that row." The form steps backward from one datetime and returns the earlier calendar stamp for a filter or ticket.
Whole seconds only—no hour field—so you are not typing zero hours when the spec is literally "minus 45 s." That keeps it separate from time-ago, which is for longer blocks in hours and minutes. Timezone conversion is not handled; use the same zone as the source column before you copy.
45 seconds before May 9, 2026 at 9:30 AM is 9:29:15 the same morning—easy to mis-type as 9:30:45 if you were thinking forward instead of back.
Log lines rarely stop at round minutes
Support still says "about a minute ago" while Elasticsearch wants an absolute bound. Running the anchor once beats mental subtraction when the seconds column is :27 or :03. Forward hops belong on the other page—45 seconds after that same 9:30 AM stamp—not a negative count here.
Midnight boundaries still bite going backward. 45 seconds before May 10 at 12:00:15 AM is still the ninth at 11:59:30 PM; plenty of people paste the tenth by habit. Longer lookbacks are easier in minutes—3 minutes before the same morning anchor—once you are past a handful of seconds.
- Reference time is the event named in the note, not "now" unless you set it.
- Check you subtracted, not added—forward results look plausible until the grep is empty.
- Keep anchor plus seconds beside the answer for Friday's thread.
When the window spans hours, not seconds, use the time-ago form instead. Display labels vs export timestamps are a common fight; the audit trail time-ago note is useful even for second-level bounds. Ordinary reference math, not legal advice.