[tz] [PATCH] tzdata: Asia/Ha_Noi: Add new timezone

[Lester Caine]

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