On Sep 2, 2013, at 12:37 AM, Paul Eggert <eggert@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.