[tz] On merging timezones - a radical proposal.

[Jonathan M Davis]

On Wednesday, May 22, 2013 12:24:39 Guy Harris wrote:
> > We already don't handle (to make up an arbitrary example) people who
> > moved from New York to Phoenix in 1992, but spent a month-long vacation
> > in Florida in 2004.
> 
> We don't handle that because UN*X APIs don't offer a mechanism for saying
> "please use the time zone I was in at a given time to convert that time";
> if they did, they could use our database for that.

D's standard library can do that sort of thing, but it's forced to read the 
files directly (and Boost has something similar, though IIRC, they maintain the 
TZ information in a different format rather than using the system's TZ files). 
The *nix C API is definitely limited with regards to time and time zones. 
However, at least *nix _has_ the right information thanks to the tzdata files. 
The built-in Windows stuff is way worse off in that regard.

In any case, to answer the general topic, I would argue that the "advanced" 
stuff is the set of time zones that people don't normally use. There are over 
1000 time zones in tzdata. Most people don't use more than one and don't care 
that most of them exist. They just pick America/New_York or Europe/Paris or 
whatever and it works just fine. I don't see any benefit in merging any of that. 
As it is, Linux installers typically either automatically determine your time 
zone or ask you to select your location on a map. In either case, you usually 
only have to worry about picking an actual time zone file when using a distro 
like Gentoo or Arch where you're managing most everything yourself directly 
rather than using GUI tools. So, I see no merit whatsoever in this proposal.

And some people _do_ care about historical dates, and the fact that the tzdata 
files do as good a job with that as they do is fantastic (in contrast, Windows 
is lucky if it gets the date and time of a DST switch right if it's not in the 
US).

- Jonathan M Davis