[tz] Dealing with Pre-1970 Data

[Guy Harris]

On Sep 2, 2013, at 2:40 AM, Lester Caine <lester at lsces.co.uk> wrote:

> Paul - MY proposal is that if the database returns LMT then it is a flag that we are working with 'pre standard time' dates, and that the actual local time is calculated using a longitude value.

In at least some code that uses the tzdb, including the tz code distributed by the tzdb maintainers, that would require that the system either be able to determine its current longitude or that somebody be obliged to specify it as part of system or user configuration.

I do not expect the latter of those two to happen on most UN*X systems, and only expect the former to happen on those UN*X systems that a user can conveniently carry; the latter is a large number of systems, however (the system on which I'm typing this is one such system, and not only will it attempt to determine an approximation of the current longitude and latitude if asked, it will also attempt to set the system tzid based on that).

I do not, however, expect many UN*X systems to bother to make localtime() and mktime() attempt to somehow get the current longitude of the system and use that to convert seconds-before-the-Epoch values that predate the adoption of standardized time at the current location, so I don't think it's a worthwhile effort to have the tz code do so.

Code that *does* do so needs no help from the tzdb or the tz code, and thus needs no work on the part of the tzdb/tz code developers, other than being able to know that the time they're trying to convert antedates the adoption of standardized time, so that they should not use the tzdb.

> Once we move into a time where there is some standardisation, then generally the zone gets a LMTZ tag

I would simply say "standardized time"; the adoption of standardized time means you *aren't* using local mean time, you're using the mean time of some specified longitude that might not be your longitude.

> indicating that it is a time applied across a whole zone. We may still have to handle the problem of 'train time' and 'government time'

*Somebody* may need to handle that; I'm not convinced that the tzdb needs to handle that.