* Alan Burlison <[EMAIL PROTECTED]> [2007-10-04 14:45]: > The current OpenSolaris user registration screens collect timezone and > location information, and I'm considering what we should do with these > in the new auth webapp, as in their current form both have problems. > > Timezone > -------- > > Currently this is built from a hard-coded timezone list > http://cvs.opensolaris.org/source/xref/website/portal/trunk/src/java/org/opensolaris/base/util/TimeZone.java > and then looking up information in the J2SE timezone class (also called > TimeZone) - see > http://cvs.opensolaris.org/source/xref/website/portal/trunk/src/java/org/opensolaris/tonic/action/user/ListInfoAction.java#40. > > I have no idea of the sanity of the resulting list, and I can see at > least one problem - the initialisation code is only run once, and it > uses the current date/time in its calculations of the GMT offset, so if > the appserver runs over a DST change, the offsets will change but the > list won't. Of course, the appserver has to be restarted every night > anyway for other reasons, so I guess we just got lucky ;-) The > aggregation of timezones by GMT offset in the current version also means > that we get less info that we otherwise might, for example Amsterdam, > Berlin, Bern, Rome, Stockholm and Vienna are all lumped together. > > My suggestion is that we just use the standard list as provided by the > Java TimeZone.getAvailableIds() method > http://java.sun.com/javase/6/docs/api/java/util/TimeZone.html#getAvailableIDs() > > preprocessing the list to discard the Etc/ entries, which are all just > GMT offsets, and the SystemV timezones, which I didn't even realise existed. +1.
> Location > -------- > > This is a freeform text field, and has a whole range of information in > it, from a full postal address, just a postal code, a geographic area, a > country, /dev/null (hilarious) and nothing at all. > > My suggestion is that we replace this with an explicit country list. > Google likes http://schmidt.devlib.org/data/countries.txt, but I'm open > to other suggestions for a data source. +1, noting that the related page http://schmidt.devlib.org/data/geo-data.html suggests that we could spend weeks picking among standards. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ website-discuss mailing list [email protected]
