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

[Lester Caine <[e-mail]>]

On 23/12/14 09:37, Daniel Migault wrote:
> This notification issue seems to me important for users. However, if I
> understand it correctly, it should be handled by the client and looks to
> me more an implementation issue. The client should regularly check the
> latest version by listing available versions on the server(s). Then it
> is up to it to take appropriated actions.

A little late replying but ...

The race problem arises where the user is looking at the current version
of TZ, but the calendar has still to be updated. YES it's an
implementation issue, but by the correct handling of version in the
protocol, the implementation actually HAS the information that there may
be a problem.

Malta is only an hour adrift from the UK, but the phone was in flight
mode for 3 hours and when I landed displayed the correct time. Great -
except there is no information as to which time zone I am actually and
I've not worked out yet what timestamp was used for the various posts
while I was away. On a long haul flight the devices will be 'off-line'
for half a day or more and need to sync to a new local time when they
re-connect. The windows when problems may arise are very small (well six
months for a browser but we will ignore that) but simply ignoring them
is not acceptable when a couple of simple steps built in now will
eliminate any race risk.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk