Copied to tzdist list as I feel this starts to fill in the gaps! On 11/10/14 06:46, Tim Parenti wrote:
I realize that including this as an actual Zone in backzone would chip away a bit at the firmness of the 1970 cutoff, and there has already been much debate over whether or not that would be a Good Thing, which I do not wish to rehash. But I feel that having a second-class area like backzone makes loosening this cutoff a bit more necessary in cases like this, so that good data like these can be preserved in case we need them again, whether within our current scope or the scope this project takes on in the future.
That the 'second class' area has 'first class' material simply because the date of change pre-dates 1970 is the whole problem. There is substantial pre-1970 data in the 'first class' area but no indication if that actually applies to the linked aliases! The discussion on the tzdist list is about 'truncation' and I've only just realised that it is just for every alias that the TZ data is only valid from 1970. Of cause the 'primary' set of data is perfectly valid back to it's start date. Personally I feel where a current alias has got first class data back to an earlier time then it should always be included in the base set. Since in most cases it IS just an extra start rule prior to another generic data set then there is little extra data. Where it becomes a problem is when the data set for an ID is always fully expanded such as on the tzdist current protocol. 'Secondary' ID's which just have a small data set prior to a more generic one post some later date are the problem. In many cases it is the start of 'DST' which forms a smaller set of 'variable' data and around 2/3rds of ID's never hit that point. I was originally looking for a flag between LMT and the start of a timezone, but the real point here is using the 'common' event time as the end marker of 'aliases' so that the handling of say Europe/UK/Oxford would have fine detail prior to Europe/UK and in this case Europe/UK/London is the 'master' for Europe/UK. Europe/Isle_of_Man/Castle_Rushen then folds down to Europe/Isle_of_Man which picks up Europe/UK at the start of DST changes rather than the start of London/GMT or 1970, both of which are wrong. It *IS* the use of an arbitrary location to identify a set of timezone data which is the whole problem of making this scale well back in time? A 'DST' data set SHOULD be a region rather than a location and a location simply has a date on which they started using that data set. In tzdist the conversion of an alias to a set of data actually needs to be a two stage process of which only the second stage is currently being developed. The TZID for Europe/London provides a set of timezone data which is accurate from 1916 and while not fully verified, all other UK locations adopted that and used that from 1916. (There are some gaps in later provenance on DST changes). Prior to 1916 there are a number of other common points such as the adoption on GMT in different areas culminating in the eventual standardisation by around 1884. Some locations like counties in Idaho are a list of changes between two of the 5 American main data sets. Most locations are a lot easier, either only having a single date for the start of the international GMT adoption, or perhaps two or three dates with a local pre GMT standard followed by the GMT change all well before 1970. 'GMT' is essentially just a fixed set of 24 offsets which is all that the large majority of locations reference and which is fine tuned by UTC in 1972, so stage one is to identify the history for a location, which can be simple if all one is interested in is post 1970 or so. This will either just give a fixed offset, or identify a dataset to use. Where I don't think the current tzdist model scales is where a large number of historic ID's only vary by a single start date. The system does not need to duplicate all the following data. -- 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