We took a different approach to the problem. We were more concerned with
time zones and less concerned with Locales, so we use Javascript to send as
part of our login transaction the millisecond offset from GMT based on the
timezone info on the browsers computer. We then use that to determine what
their timezone is and we persist a timezone object with their session
object (ClientInfo?).
Drawback is it doesn't tell us what locale they are in. Advantage is it
tells us exactly what timezone they are in and it works great on our
supported browsers (4.0 and up, NT, IE & Communicator).
Bill
Robb Shecter <[EMAIL PROTECTED]> on 03/03/99 06:47:13 AM
Please respond to "A mailing list for discussion about Sun Microsystem's
Java Servlet API Technology."
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Bill Kayser/Worldstreet)
Subject: RFC: Getting language and TZ info: ClientInfo.java
Hi,
I'm attaching a class I wrote because it may help others, and also to
get comments about the wisdom of doing some like this.
I want to be able to tailor the HTML output of my servlets to the time
zone that the user is from. I also want to be able to make the format
in which dates are printed as normal for the user.
This class, ClientInfo, takes a ServerRequest paramter in its
constructor. It parses out the Top Level Domain, and uses that to
create appropiate Locale and SimpleDateFormat objects.
I'm not sure about a couple of things, though:
- I've only made mappings for the default locales that are defined in
the Java API. What would I do if I wanted to include support for more
locales? Write the locales myself? Anyone have any examples of this?
- Is it really necessary to set up a mapping between TLD and locale like
I'm doing? Could that be done in a more scalable, automatic way?
Thanks for any comments,
Robb
ClientInfo.java
