Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Ken Murchison <[e-mail]>]

On 12/10/2014 01:34 PM, Lester Caine wrote:
> On 10/12/14 17:51, Tim Parenti wrote:
>> I do agree that, given the intended use of tzdist and the intended speed
>> of update propagation, the potential hazard here is negligible.
> Apparently a lot of ISP's cache pages when they read them, and do not
> necessarily update them even if the source page changed. That caching
> may even be the browser on your computer! The 'potential hazard' is far
> from negligible!

Section 4.1.4 gives recommendations on the interval for servers and 
clients to poll for updates.  If a client or server caches data for 
longer than this before updating and users start missing meetings, the 
users will stop using those clients and servers.  This is an 
implementation problem, not a protocol problem.

If short term changes to published TZ data occur within these polling 
windows, a version number won't solve the problem anyways. And even if 
the short term changes are published outside of this window, there is no 
guarantee that a primary server will be updated by an admin outside of 
the polling window, so again, a version doesn't solve the problem 
(unless you expect client to know what the expected version should be 
via some OOB mechanism).

Some of this depends on the definition of "short term change".  If 
"short term" means that new TZ data gets published less than a day prior 
to a change, then I don't see how tzdist can be expected to handle 
this.  If "short term" means a few days, then I would fully expect that 
well-behaved admins would update primary servers ASAP and that 
well-behaved secondary servers and client would gets updates during a 
polling interval that takes place prior to the impending time zone change.


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University