Dates are the hardest field: handling deadlines that change after you publish them

If you publish anything with a deadline on it, such as event listings, tender notices, admissions or job openings, you already know the awkward truth: the source changes the date after you have published it, and it does not tell you.

We run a jobs portal for India, and deadline extensions are the single largest source of corrections. A few patterns have made them manageable.

1. A date is a claim with a source

Store each date together with where it came from and when you saw it:

{
  "field": "closing_date",
  "value": "2026-03-24",
  "source": "corrigendum-1.pdf",
  "seen_at": "2026-03-09",
  "supersedes": "2026-03-14"
}

Now a correction is an append, not an overwrite, and you can always answer the question of what the page said last Tuesday.

2. "Unknown" must be a valid value

When an exam is postponed with no new date, the honest state is to be announced. If your schema or UI forces a date, someone will type a guess, and guesses get screenshotted.

3. Show the change, do not hide it

Render the old value struck through next to the new one with a link to the notice. It costs a line of UI and removes most "is this right?" emails.

4. Derive, do not duplicate

"Closing soon" badges, countdowns and reminder emails should be computed from the latest assertion at read time. Anything cached with the old date will be wrong the day after an extension.

5. Time zones and end-of-day

"Last date: 24 March" almost always means 23:59 local time at the source, and occasionally means 17:00. Record the time when the notice gives one, and never convert a date-only value through UTC.

6. Re-check on a schedule that matches risk

Listings within a week of closing are the ones most likely to be extended. Re-verify those daily; everything else can wait.

None of this is clever. It is just treating published dates as versioned data. You can see the result on our latest government jobs listings at Govtpvt.