[tz] State of the tzdb

[Lester Caine]

Guy Harris wrote:
>
> On Sep 3, 2013, at 4:43 AM, Lester Caine <lester at lsces.co.uk> wrote:
>
>> Stephen Colebourne wrote:
>>> We're a lot further forward now to regaining stability, but there are
>>> a few points still outstanding.
>>>
>>> 1) Should there be one zone ID in the main files (not "backward") for
>>> each inhabited ISO-3166 code?
>>>
>>> I've argued for this as a reinstatement of a rule of 16 years standing
>>> which is no more than common sense.
>>> Paul has argued against.
>>
>> A debate on openstreetmap at the moment relates to the status of historic information in that database. Many people feel that if it does not currently exist on the ground, then it should be removed. It is a little of an academic discussion since the data will remain in the change logs anyway, but it's access to that data which is at question. The current proposal is that some data is archived to an openhistorymap which will allow the use of a 'date' to define what data is displayed, but in many cases the bulk of the main database needs to be combined with the small amount of history to create the final dataset anyway, so openhistorymap has to have a complete copy of the main map! You can't define a reason for NOT including something in the historic map.
>>
>> Not to dissimilar to what we are talking about here?
>
> You're talking about historical data, so you're presumably referring to this point in Stephen's message:
>
>> 5) Pre-1970 data
>> Some of this seems uncontroversial at this point (don't remove data,
>> don't create new IDs just for pre-1970). Some of it is still under
>> discussion. Only enhancement of existing IDs is necessary to the
>> applications I work with.
>>
>> As noted in the other thread, removing IDs that only differ in LMT is
>> harder than initially thought, as the start of fixed offsets and the
>> name of fixed offsets are pieces of data covered under the no deletion
>> rule. As such, it is unlikely that there are many possibilities for
>> merging zones.
>
> not to the quoted point, which was about ISO 3166 country codes.  If, for example, you're talking about rules within the UK, those all correspond to a single ISO 3166 country code, so his point about ISO 3166 country codes doesn't apply.

The I was not talking about any particular statement, but the generality of 
removing older data from a system that is in active use. Many of the comments 
relate to winnowing old data and essentially ignoring the historic material. I 
on the other hand would prefer to be able to retain the pre-1970 material in a 
format that can be used in exactly the same way as any other time window.

I'm not sure as yet that we have agreement on exactly what historic data is 
fundamentally correct and what needs winnowing simply because it IS on shaky 
assumptions? The data that I've reviewed confirms what I had already assumed and 
is valid back to the 1880's and I think there has been a similar statement 
relating to US data? I've already outlined what I think is a good compromise to 
bring in LMT information without adding extra zones, along with the maintaining 
of extra pre-1970 data which just creates additional zones for just a short 
period of time. I'm just not sure anybody agrees with my analysis? A system that 
returns a list of timezones based on a supplied date would seem to me to 
simplify everything without loosing the critical historic zones? And move far 
enough back we just use LMT (or solar time) based on longitude ...

-- 
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