[tz] Recent conversions of zones to aliases

[Guy Harris]

On Oct 3, 2014, at 12:10 PM, Lester Caine <lester at lsces.co.uk> wrote:

> On 03/10/14 19:49, Guy Harris wrote:
>>> But it is more than that. There are definitely people upset to see their timezone reported as being that of a city in a different country, simply because they happened to have the same rules. Most of the above have small populations, where one could argue that it doesn't matter much (and Kosovo is a special case).
>> Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics (and of population shifts).  (That might also force systems to have better mechanisms for selecting time zones than "put up a bunch of tzids and let the user pick one".)
> 
> The data is not directly location based, so perhaps the proper tidy here
> is a switch to abstract ID's to get away from any 'political bias'.

Yes, that's what I meant by "Yes, it would be nice if we had abstract identifiers for timezones rather than something that reflects the effects of politics..."

That would also mean we wouldn't have to worry about what happens when city A no longer has a bigger population than city B, as per "...(and of population shifts)."

> This then allows a location to TZID mapping system perhaps geonames based to
> include the start date, and then augment the TZ data with local offsets
> prior to the relevant data set becoming active.

Is the local offset calculable from the location?  If so, then:

	the tz database should provide the data it provides currently, using tzids;

	whatever code uses *locations* to convert between local time and (proleptic) GMT should

		1) have a database to map locations to tzids;

		2) be able to determine from the tz database whether there was a form of standard time in effect at the time it's trying to convert;

		3) if standard time is in effect, use the tzdb information to convert the time;

		4) if standard time is not in effect, use the local offset to convert;

so that all the tz data needs to have is an indication of when standard time began.  The local offset of some specific location in the timezone isn't needed for the above; as I understand it, it's necessary only because the tz code needs to have *something* there for the benefit of code that isn't using the location and that, presumably, doesn't care about getting a *meaningful* value for pre-standard-time timestamps.