3.8 and french (and locales)
Andreas Raab
andreas.raab at gmx.de
Wed Jun 8 05:11:06 UTC 2005
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
More information about the Squeak-dev
mailing list
|