[tz] On merging timezones - a radical proposal.

[Guy Harris]

On May 22, 2013, at 11:27 AM, random832 at fastmail.us wrote:

> Or, more precisely, on the subject evicting redundant timezones from the
> user selection menu, since of course all current names will continue to
> exist as links if nothing else.
> 
> I've thought about this some more, and I don't think it goes far enough.
> A user installing a new system doesn't _care_ about (my own proper time
> zone) America/Indianapolis, they don't have any need to accurately
> convert times from before _2006_ let alone 1970. Most users could
> probably be served just as well with America/New_York.
> 
> I think it would be useful - particularly if we're abandoning being able
> to narrow it down by country - to define a heavily cut down set of
> "basic" time zones, that define each set of rules that exists _now_
> without care for maintaining the past back to 1970, and then offer an
> "advanced" option for the rest.

"The rest" would probably include most if not all UN*X systems:

	http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html

does not contain the string 2006 anywhere in it, so I view it as making an implicit promise that localtime() can convert any value of "seconds since the Epoch" to local time, and I wouldn't assume that there are no applications that depend on that working for older dates (and that matter and will cause loud complaints by users and/or independent software vendors that version $VERSION of $UN*X broke things).