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

[Doug Royer <[e-mail]>]

 VTIMEZONE has a last-mod property. When that value changes, it should
invalidate the cache. It should be valid for version control.

Broken proxy servers seem out of scope and if they exist, a version ID
would not change anything.



-
Doug Royer
[e-mail]
[phone]

On Wed, Dec 10, 2014 at 11:55 AM, Ken Murchison <[e-mail]>
wrote:

> 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
>
>
> _______________________________________________
> Tzdist mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tzdist
>