Re: [Tzdist-bis] draft-tzdist-geolocate

[Lester Caine <[e-mail]>]

On 24/10/2018 17:08, Eliot Lear wrote:
> On 24.10.18 18:05, Matthew Donadio wrote:
>> Problems with historical data aside, I have museum friends /
>> archivists who would probably be interested in this as they work on
>> back-annotating their collections.  Data would either be from the EXIF
>> in the images directly or in the DAMS / collections management system.

> Yes, I think that is also (at least in part) Lester's use case if I'm
> not mistaken.  The question is whether you need a protocol for that
> purpose or merely a software capability that can consume the TZDB and
> perhaps other information.  In answering this question it boils down to
> who will write the implementation.

This is not really a matter of 'writing an implementation', but simply 
defining what happens when a time and location stamp is processed. 
Handling uncertainty as to just which ident IS correct needs to be part 
of that process?

Images with a location, are then normalized time wise using the current 
offset for that location. In N years time provided that the offset has 
not changed then everything is fine, but if any element of selecting the 
offset has changed this may not be the case. geolocate may well be 
giving a different tz identifier as has been demonstrated, and in 
addition the rule set that was used originally may have been 'corrected' 
for some reason so one needs to know in addition to the location and 
time, the versions of data used to generate the offset! SIMPLY asking 
for the current identifier associated with a location in Paul's model 
requires that the identifier does not change at all over time ... only 
the rules set changes and tzdist's ability to monitor changes over time 
solves the problem of whether an historic normalized timestamp can be 
relied on. If geolocate returns a different identifier then the tzdist 
may not be able to help? If there is uncertainty as to the correct 
offset then at least recording what rule was used allows historians to 
pick up on the problem and perhaps correct just what geolocate should 
have returned?

An historic tag has to consist of location, UTC time, tz publisher, zone 
identifier and version. Simply storing a location, UTC time and offset 
as some databases currently do may work for today, but in N years time 
we once again have an element of uncertainty if the current rule set for 
the location does not match that used previously. In my book, the 
problem comes when pre-1970 material for which we know accurate times is 
messed up because geolocate only returns post-1970 identifiers without 
any warning that the data then accessed from tzdist IS going to be wrong!

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