Re: cache freshness / age calcs

Adrien de Croy wrote:
> This case is where the origin server has a clock that is way out of
> whack, and specifies expiry times close to the level of error.  No Age
> header, so presumably not from some intermediary cache.

Thanks to our stupid government, expect to have that kind of problems from
the user agent side soon.

This month, Argentina switch to DST, once again giving the exact switch date
one or two days in advance. Some provinces will refuse; it's still
uncertain which, they're still discussing it.

Last year, there was *no* update for Microsoft Windows to fix the timezone
database for Argentina; Microsoft couldn't develop, test, and deploy an
update out in time. And even if they did, Windows has one timezone for the
entire country, so there is just no way it would automatically work for all
provinces.

The tzdata database used in most Unix systems has always had one timezone
per province. But the tzdata maintainers will have to (again!) be watching
news and the congress website frequently to get an update as fast as
possible once the final law is out. Last year one province gave the final
notice saying they wouldn't switch a few hours in advance, keeping the
tzdata maintainers quite busy... And then more time will pass till Linux
distros package the update, and users upgrade.

Guess what most people will do, especially those who use Windows (vast
majority) and who probably won't get an update? Change the *clock* manually
(not the timezone), screwing up the computer's notion of what UTC is.


And I'm sure HTTP caches and cookie expiration timestamps would be some of
the many things that will have problems. Do major browsers currently adjust
cookie expiration timestamps for differences between local time and server
time? And would they adjust for differences as large as *two* hours?

Received on Monday, 12 October 2009 04:15:40 UTC