Hi Lex -

> I would suggest, though, that the time parts be cut back for now,
> given the now-known race condition.  Instead of reporting all that it
> does, just have it report the prefered time zone, and let the
> image-level code do timezone computations.

What would be the point in that? If you don't want the information just 
don't use the primitive.

> I'm sorry I didn't see this spec before and so could not comment on it
> before now, but I'm also curious why this problem is in the spec since this
> topic has gone around the mailing list several times and I consistently
> pointed out the potential race condition if you aren't careful.  Do people
> disagree this is a problem?  I don't think it's a *big* problem, but it is
> a real pity to enshrine it in an API that we will probably be stuck with for
> a while, and there is a solution that isn't hard.

It isn't hard but potentially costly. You assume that the timezone 
information is readily available. What if it isn't? Suddenly you have 
enshrined that any platform that does not have the information readily 
available (and remember: Your assumption is that the time zone *changes* 
so this might require a roundtrip to some time server to find out what 
time zone you are in) must have this very slow primitive. So, yes I both 
disagree that it's a problem and I disagree that your solution has any 
advantages in practice. To the contrary. If there is any app which 
really needs realtime time-zone info it is free to call "Time 
updateTimezone" (or whatever the relevant method is called) when it 
feels like it needs realtime time zone information (as a matter of fact, 
if it wants to be really sure it should check before *and* after to be 
sure the time zone hasn't changed).

> If we are in a hurry to have local time support, we could do
> worse than using the already-implemented TimePlugin that I wrote in
> 2000.  It supports querying local and UTC times without the race
> condition described before.  Its main limitation is that it only goes to
> seconds granularity.

That's a red herring. Remember what this thread is called? It's about 
locales not timezone. You raised an (in my understanding obscure) point 
and I don't think this point needs any immediate reaction (if it needs 
one at all).

> Also, don't forget Dave Lewis's code for doing timezone computations.
> Race condition aside, I don't see any reason at all to write new code that
> just uses an offset, when he has already released all the code necessary
> to do timezone computations properly.  (Or at least, to the level that
> people expect from typical desktop software.)

Where is this code? It might be interesting. How does it find out what 
the current platform's timezone is?

Cheers,
   - Andreas