[tz] Proposed reversions, for moving forward
zoidsoft at gmail.com
Sun Aug 10 09:37:46 UTC 2014
On 9 August 2014 00:51, Paul Eggert <eggert at 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
> few applications that could conceivably use this old data (mostly
> 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 at alum.mit.edu> wrote:
> On Aug 8, 2014, at 2:24 PM, Stephen Colebourne <scolebourne at joda.org>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz