The TZDB has few issues after 1970 as far as I can see, but before that date there are debates about what should be included and what should not. Options include - nothing at all before 1970 (but the format demands something...) - only data that has some reasonable source before 1970 - include data before 1970 even if its source is less than ideal Ultimately, the problem revolves around the data format (which cannot realistically be changed) and LMT. In the past there have been various discussions around LMT with the conclusion that it is a bit of a silly concept, because it refers to a single location, not a region. But we are in the position where the format requires it, and it is widely used (even if that use is accidental rather than deliberate). Broadly, my position is that where data can be verified pre-1970, such as in the UK, or my recent Angola email, it should be retained. Commentary should be added to the data files to justify the data that is present. Where the data cannot be verified, I am willing to take a judgement call, provided that the judgement call is not just "we don't know so lets link it elsewhere". What I find objectionable is to have a named entity (zone or link) where the LMT of the named location is replaced by the LMT of some other location. I understand that others may not care, but it seems flat out wrong to me (and is key to solving the pre-1970 problem). Therefore, I'd like to propose a simple alteration to LMT. I propose that all LMT values in the database are replaced by an new value, representing what could be described as "averaged/smoothed regional far past time". In real terms, this means changing all the LMT values to an appropriate fixed value for that location. Once the fixed value is chosen, there should be no reason not to retain it forever. The intention is that the fixed offset value is the most common standard offset used by the location, favouring an offset close to the LMT if ambiguous. The offset chosen would typically be a multiple of 15 minutes, and not contain seconds at all. To help frame the debate, I produced a list of zones and all their *standard* transitions (excluding DST) for 2013h; https://gist.github.com/jodastephen/03487c61782e612db85d Some examples: Europe/London -00:01:15 LMT Z 1847-12-01 My proposal is to change the LMT value from "-00:01:15" to "Z" America/New_York -04:56:02 -05:00 1883-11-18 My proposal is to change the LMT value from "-04:56:02" to "-05:00" America/Panama -05:18:08 -05:19:36 1890-01-01 -05:00 1908-04-22 My proposal is to change the LMT value from "-05:18:08" to "-05:00". If justification for the "-05:19:36" value cannot be found, then that should be removed. The net effect of this would be to provide a much more regularized value for the far past (pre 1850 or later). In most cases, the new LMT offset would be the same as the first non-LMT offset, resulting in the removal of a messy transition, leaving only a name change (eg LMT to GMT). Advantages - regularized far past (my experience shows that developers find the LMT seconds offset confusing when they see it) - increased stability, once adopted there is no reason for the LMT value to change - minimizes churn in the database due to "more accurate" longitude/latitude - allows the same offset to be used even if the largest city changes in a region - typically aligns the far past with the first "real" zone definition line - allows multiple locations to be linked (as per recent changes) without debate about changing any timestamps in most cases - when multiple locations are linked, only the start of regular time is then significant data (where known it should be retained) Disadvantages: - changes the meaning of LMT (the name could be possibly be changed to FPT - far past time) - loses existing LMT data (it could still be made available in a separate file) - requires a one-off change I hope that this proposal can be considered, as it would seem to address the majority of the issues in a simple and neat way that benefits most downstream consumers with extra regularity and stability. Stephen