Not as wonky as you'd think, and 60 minutes means something much different than 12:15. Which can be good and it can be bad, but many of my experiences with TTLs have not been pleasant. 60 minutes, as typically implemented, means some user out there has data that is 1:58 stale and he's yelling at your boss on the phone who is now trying to figure out if he should be passing the favor along.
See also ETags which stop trying to be clever about dates and instead be clever about the contents of the message.
Why I like the Date header is that it works well with REST endpoints that care about time but for whom caching is either not a good idea or is orthogonal.
> Not as wonky as you'd think, and 60 minutes means something much different than 12:15.
The expression you’ve posted is literally a complicated way of writing 60mn, and you specifically wrote that it should not be interpreted as 12:15.
> See also ETags which stop trying to be clever about dates
Etags have unrelated role and semantics. Etags go with last-update, which doesn’t suffer from anywhere near as much from drift because it’s checked by the server, which emitted it.
Which makes for a wonky mess, and I guess is why Cache-Control did away with the entire thing and just tells you how long the response is fresh.