[tz] On merging timezones - a radical proposal.

[Guy Harris]

On May 22, 2013, at 12:12 PM, random832 at fastmail.us wrote:

> On Wed, May 22, 2013, at 14:55, Guy Harris wrote:
>> "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
> 
> Those go back to 1907, and that's on 32-bit systems.
> 
> The thing is, most users won't actually _have_ files whose timestamps
> they care about to-the-hour accuracy in displaying their timestamps in
> local time. And those who do can pick advanced.

Define "users".  Do you mean "administrators" for big machines and "end users" for personal machines?

Presumably if users can "pick advanced", the *system vendors* have to ship the full set of time zone files (otherwise, "advanced" isn't available).

As long as they're doing that, presumably "pick advanced" is an option used in whatever UI is offered to choose the system's time zone, which will, for example, mean that, for the US, options such as "that part of Indiana that didn't do DST" will show up only if they "pick advanced".

Of course, it's ultimately up to the system vendors to decide whether to offer "pick advanced" as an option or just to make it the default (or not to offer "advanced" at all, but I really doubt they'd do that).  If they don't deem this choice useful, I suspect it's not worth our while to offer it.

> 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.