Skip to content
FiskHub

hr.date_in_future

HTTP 400   type: validation_error   param: occurred_at
{
  "error": {
    "type": "validation_error",
    "code": "hr.date_in_future",
    "message": "occurred_at is 2026-08-28T10:32:11+02:00, which is in the future. A sale cannot be fiscalized before it happens (restrictive error 177). Check the device clock.",
    "param": "occurred_at",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.date_in_future"
  }
}

What happened

occurred_at is later than now. Croatian restrictive error 177 rejects a sale dated in the future, and FiskHub catches it locally before sending.

A small tolerance is allowed for ordinary clock drift; this error means the difference is beyond it.

Should you retry?

Not unchanged. Fix the timestamp or the clock first.

The fix

Almost always one of three things.

The device clock is wrong

The usual cause. Unattended machines run for months without supervision, and a clock that drifts or resets after a power cut will happily date sales in the future.

  • Enable NTP on the device.
  • Check the clock as part of the maintenance routine.
  • If a battery-backed RTC resets on power loss, treat a suspiciously wrong clock as a reason to refuse to sell until it is corrected — a sale with an unknown timestamp is worse than a sale not made.

The timezone offset is wrong

{ "occurred_at": "2026-08-27T10:32:11+02:00" }  // correct: Zagreb, summer
{ "occurred_at": "2026-08-27T10:32:11Z" }       // two hours later in real terms

Sending Zagreb local time labelled Z shifts every sale two hours into the future during summer time, and one hour in winter. Croatia is UTC+1, UTC+2 during daylight saving. Emit the offset your device actually has — most languages do this correctly if you ask for an offset-aware timestamp rather than formatting a local time by hand.

Something is generating the timestamp

If occurred_at is computed rather than captured, check what it is computed from. Adding a buffer, rounding up to the next minute, or taking the expected completion time of a dispense cycle will all produce this.

occurred_at is the moment the sale happened. Capture it at that moment.

Verifying the fix

Terminal window
# What the device thinks the time is, in the right format.
date -Iseconds

Compare with the offset your integration sends. They must agree.