Tim Rowledge <tim at rowledge.org> wrote:
> "Lex Spoon" <lex at cc.gatech.edu> wrote:
> > Most of that spec sounds good, although it is overkill for the question
> > at hand the language by itself would work.  All we need is a stupid
> > primLanguage function that has a fallback to an image-level preference. 
> > This might make a great hacking session on #squeak some time if you can
> > gather VM hackers for at least two platforms.
> A LocalePlugin is already written to the spec Mike Reuger passed around a while
> back and it will appear in the next release of VMMaker. I even have a sample
> implementation of the platform specific parts for RISC OS.

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

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.

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.

http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/014127.html

If this sounds interesting, I can probably find some time this weekend
to tune it up in whatever ways people would like.  Since it uses
common Posixy functions, it will probably compile without modification
on a large number of platforms.

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

Marcus, I share your general frustration, but I think it is more an
issue of having good leaders than having the raw work available.  As
you can see, there is a wealth of raw code available at this point, and
there appear to be plenty of people willing to do the work.  We just
need leaders who will act on it, and in this case it looks like Tim is
has stepped up to move things along.

-Lex