On 9 August 2014 00:51, Paul Eggert <eggert@cs.ucla.edu> wrote:
> This is based not only our experience with doing
> these tz changes in the past (we've done 'em, multiple times, for many
> years, with no problems reported); it's based also on my experience with the
> few applications that could conceivably use this old data (mostly astrology,
> but also earthquake records and the like)

Stephen Colebourne wrote:

This is a far too limited view of the usages of the data, perhaps that
is part of the problem here. The reality is that millions of
developers use this old data, it is just indirect rather than direct.

1) Most developers are not aware of the nuances of coding well using
date and time, and especially not times in the past.

-------

Agreed. I used Jean Meeus's "Astronomical Algorithms" text to program date and time conversions using Julian dates which includes calendar conversions as well. If one is calculating sky positions for an observer in a given location then this time zone data is very important. Those who are astronomically sophisticated will generally use UTC, but if one wants to accurately represent sky positions coming from a wall clock from the past, the tzdata is very important. There are other factors such as delta time which can only be guessed at and become more error prone the farther you go back into the past so tzdata inaccuracy is not the only problem, but one does the best they can. Tossing out data because it isn't authoritative enough defeats this particular purpose. What I have done in the Terran Atlas is highlight those questionable areas and bring up a popup warning so users can make a judgement call.

On Sat, Aug 9, 2014 at 1:52 PM, Guy Harris <guy@alum.mit.edu> wrote:

On Aug 8, 2014, at 2:24 PM, Stephen Colebourne <scolebourne@joda.org> wrote:

> While some may argue that LMT is a stupid concept, the reality is that
> the database format requires it, and it has been widely relied upon by
> consumers of the data. As such, LMT should be accurate, or technically
> at least accurate for each zone that differs beyond 1970 and for each
> at least one zone per ISO-defined region.

Presumably meaning "accurate for some particular location in each zone...", as a sufficiently-wide zone contains locations whose LMT would differ by a second or more.