I was reading this and realizing that he was mixing two very different things: design considerations and design errors. Treating every year as 365 days is a design error. Leap years will break it. "Timezones next to eachother don't require changes of more than 1 hr" might also doom that F22 flying across the international date line (ok, I am assuming that was more of a test assumption than a code assumption).
On the other hand, requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. This is why Kerberos is usually used with something like NTP.
But beyond this there are a lot of things you can't do (like expire cookies) if you don't assume that client and server have similar times on their clocks. Sometimes it makes sense to require things you can't assume to always be true.
> requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration.
Right. I love this. You can't assume it unless you document it as a requirement and make someone else make it true for all the systems your software runs on.
Never forget that specifications are a contract, an agreement entered into between the implementer and the user. If either side lets down their end, the agreement is void and the software can only fail. Either.Side.
Even if you have a mathematical proof that your software is correct, it's still only correct given certain assumptions taken as axioms in the proof. Violate those axioms and your software can't be held responsible.
> Even if you have a mathematical proof that your software is correct, it's still only correct given certain assumptions taken as axioms in the proof. Violate those axioms and your software can't be held responsible.
"Beware of bugs in the above code; I have only proved it correct, not tried it." - knuth
On the other hand, requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. This is why Kerberos is usually used with something like NTP.
But beyond this there are a lot of things you can't do (like expire cookies) if you don't assume that client and server have similar times on their clocks. Sometimes it makes sense to require things you can't assume to always be true.