The territory IDs in I18N are the ISO standard country codes, not related to time-zones. I suspect that the underlying data (CLDR) may be of use, rather than the i18n project itself (which is essentially a proof of concept alpha)
Joda-Money code works as far as I know, however I may yet change the API. I would welcome a user and feedback on the API, as I do need to get it released. Stephen On 30 November 2010 13:39, Tauren Mills <tau...@groovee.com> wrote: > Stephen, > Thanks for the feedback. I had looked over the API and had a feeling > joda-time wouldn't help with most of this. I haven't looked at > joda-time-I18N yet. Thanks for the suggestion, I'll check it out. > So are Territory IDs only two character country codes? Or do things like > "America", "Africa", etc. work as well? > I don't see joda-time-i18n available via maven. Is it not stable enough to > use in production? > Also, how's Joda Money coming along? Any reason to not use it in production? > I need a money implementation and it looks really good. Debating between it > and Martin Fowler's implementation in one of his books. > Thanks again, > Tauren > > On Tue, Nov 30, 2010 at 3:09 AM, Stephen Colebourne <scolebou...@joda.org> > wrote: >> >> There are lots of good ideas here. There is no way to get groups of >> zones from joda-time though. >> >> One thing to look at is joda-time-I18N, which uses the CLDR data to >> provide some nice methods for managing time zone information including >> the most important zone per territory. Probably not enough for you, >> but it may help. >> Stephen >> >> On 30 November 2010 10:32, Tauren Mills <tau...@groovee.com> wrote: >> > I'd like to implement a UX that makes selecting an appropriate timezone >> > very >> > simple. This is for a web application, but could be for any >> > application. >> > When a user creates a profile, they need to select or verify their >> > current >> > timezone. Instead of presenting the user with a massive list of 500+ >> > zones >> > from DateTimeZone.getAvailableIDs(), I want to present them with a few >> > very >> > likely options, with the most likely timezone already selected. Of >> > course >> > there will still be a way for them to select "Other" to select from all >> > available timezones. >> > Here's how I see it working: >> > 1. Application server is accurately set to UTC and runs ntpdate >> > regularly >> > 2. Web client detects user's current local time and passes it to the >> > server >> > 3. Server attempts to determine timezone in several different ways: >> > A. Given the current server time in UTC and the user's current time >> > in >> > some unknown timezone, generate a list of potential timezones >> > B. Server performs a timezone lookup based on IP address of >> > >> > user (http://stackoverflow.com/questions/2763263/how-to-get-clients-timezone-offset-from-his-ip-address) >> > C. If user allows it, server performs an HTML5 geo-location and >> > determines timezone from lat/long >> > >> > (http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude) >> > 4. Server combines the results of options A, B, and C to generate a >> > short >> > list of potential timezones the user is within, ordered from most likely >> > to >> > least likely with most likely selected. >> > 5. User is presented with this short list of timezones, with most >> > probable >> > selected and an "Other" option to pick from the entire list >> > In fact, I could see the UI looking something like the following site, >> > but >> > simplified. The list would be comprised of many of the same timezone >> > aliases, such as "America/Los_Angeles", "America/Vancouver", >> > "America/Tijuana", etc. Your current time would be shown along with the >> > current time in each timezone. Each timezone alias would be selectable, >> > with >> > the top most selected by default: >> > http://everytimezone.com/ >> > Obviously, the user's time is likely to be inaccurate -- certainly not >> > the >> > same as the server's time. And there is the delay between when the time >> > is >> > taken on the client and sent to the server for processing. So the logic >> > would assume that the time sent from the client could be off by minutes. >> > The >> > closer their time is to accurate, the more precise the suggested >> > timezones >> > would be. I'm not worried about those users who's clock is completely >> > wrong. >> > >> > Just thought I'd ask for suggestions or comments before beginning >> > implementation. Sorry if this is slightly off-topic, but it does pertain >> > to >> > some specific Joda questions: >> > 1. Are there any features of JodaTime that would significantly simplify >> > or >> > help with step 3A above? >> > 2. Is there a way to get a list of timezone "groups" from Joda (such as >> > "Africa", "America", "US", "Etc", and so forth)? This would allow >> > timezones >> > from "America" to be preferred over "US", as the US zones would not be >> > given >> > as options. >> > 3. Any suggestions on how to best integrate timezone "preference" >> > information? For instance, as of today, it is better for a user to pick >> > "America/Los_Angeles" than it is to pick "US/Pacific", "PST8PDT", >> > "UTC-08:00", or "GMT+08:00". I'd like to only show the "preferred" >> > timezones. >> > 4. Any suggestions on how to best integrate timezone "usage" or >> > "population" >> > information? For instance, if it is 12:00 noon local time and the server >> > says it is 20:00, then options for UTC--8:00 should be shown. But I'd >> > like >> > to show "America/Los_Angeles" before "Pacific/Pitcairn". >> > 5. Are there any serious flaws I haven't considered in this approach? >> > Thanks, >> > Tauren >> > >> > >> > ------------------------------------------------------------------------------ >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> > Tap into the largest installed PC base & get more eyes on your game by >> > optimizing for Intel(R) Graphics Technology. Get started today with the >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for >> > grabs. >> > http://p.sf.net/sfu/intelisp-dev2dev >> > _______________________________________________ >> > Joda-interest mailing list >> > Joda-interest@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/joda-interest >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> Tap into the largest installed PC base & get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Joda-interest mailing list >> Joda-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/joda-interest > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Joda-interest mailing list > Joda-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/joda-interest > > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
