[tz] Dealing with Pre-1970 Data
guy at alum.mit.edu
Mon Sep 2 07:58:00 UTC 2013
On Sep 2, 2013, at 12:37 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> Guy Harris wrote:
>> you're probably *still* going to get multiple cities within the same zone
>> even if you change the cutoff to 1911 or even 1891:
> Absolutely. The further back you move the cutoff,
> the more zone splits you get, but if we're only talking
> about standard time there is a limit of the total number
> of zones.
And if we're talking about LMT, we're not talking about standard time.
>> "why should certain cities be blessed by the tzdb by virtue of having their
>> particular local solar mean time in the database"?
> The answer to that is the same as the answer to the question
> "why should certain cities be blessed by having their names
> in the tz database at all"? They're the largest
> cities in their respective zones, that's all.
(An answer that has caused some issues on the list, e.g. "butbutbut Mumbai has a *lot* more people than Kolkata" or "why not Beijing" or "why is Zagreb only there for backwards compatibility"?)
>> maybe we should just have localtime() return NULL for times
>> prior to the adoption of standard time
> That might make sense. And it would conform to POSIX
> in practice, since standard time was introduced everywhere
> before 1970, and POSIX doesn't define behavior before 1970.
> Still, it would be a little weird for localtime() to stop
> working for dates before 1847 when TZ='Europe/London',
> simply because the time was different in London
> than it was in (say) Oxford.
If somebody happens to have a seconds-before-the-Epoch value from before 1847, if they want to know what it corresponds to as year/month/day/hour/minute/second in local time, they'd better say what the longitude was of the locality in question; if they didn't, the correct answer is "mu", and NULL/-1 are popular ways of expressing "mu" in C.
More information about the tz