MySQL Bugs: #30327: Updating from previous to 1.2 doesn't update the timezone and locale controls

Bug #30327	Updating from previous to 1.2 doesn't update the timezone and locale controls
Submitted:	9 Aug 2007 4:37	Modified:	23 Aug 2007 23:44
Reporter:	Bill Weber	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S3 (Non-critical)
Version:	1.2.0.6993	OS:	Any
Assigned to:	Joshua Ganderson	CPU Architecture:	Any
Tags:	mer 120

Description:
After updating from a previous version (1.1.1) to 1.2, the "Timezone" and "Locale" controls on the User Preferences page. The reason for this is that the labels for these are now different in 1.2 than in previous versions. For example here are the settings in preferences from the previous version after the update:

*************************** 9. row ***************************
 user_id: 1
property: user.locale
   value: english-usa
*************************** 10. row ***************************
 user_id: 1
property: user.timezone
   value: US/Pacific

Here are the same settings after setting them in 1.2

*************************** 9. row ***************************
 user_id: 1
property: user.locale
   value: en
*************************** 10. row ***************************
 user_id: 1
property: user.timezone
   value: America/Los_Angeles

How to repeat:
see above

Since the locale setting only affects numeric formatting for now, let's put a small text hint to the right of the locale control that says:

  Currently only controls numeric formatting

This is a feature regression and therefore a higher priority than new bugs.

Updated the timezone stuff to use the values from php, updated the display names, did some refactoring to the usage of the timezone list. Tests indicate that this works correctly.

The locale stuff has been updated to push the user set locale into the context for struts to auto-magically format dates. This was done in conjunction with the removal of the default date format from the default properties file so that struts uses it's internal logic for deciding format. The logic has been centralized so that the server can also use this locale.

Pending work for 1.2 - try to get the php locale ids resolved with the java ids.

In the future we're likely to add the date formats back to locales. This must be done in conjunction with adding properties files for common locales and setting their date formats correctly.

r7170,7171 trunk
r7173,7174 br_6559_1.2.0