Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
From Miles Huang:
The entryAdd and entryEdit action will have some strange behavior when jvm's
default locale differ from en_US, for example, "zh_CN".
When the pubTime is set by the client side calendar, entry add or edit
operation will success, but the entry's pubTime is changed to updateTime
constantly.
In roller.log, following exception is logged:
ERROR 2007-08-10 15:45:06,562 EntryBean:getPubTime - Error calculating
pubtime
java.text.ParseException: Unparseable date: "08/01/07"
at java.text.DateFormat.parse(DateFormat.java:335)
at
org.apache.roller.weblogger.ui.struts2.editor.EntryBean.getPubTime(EntryBean.java:227)
...
This is because the client side CalendarPopup and server side
DateFormat.parse use different date format. The client side use "MM/dd/yy"
format constantly. But in EntryBean.getPubTime, the DateFormat used to parse
the date string is get by:
DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT);
It will return a DateFormat depending on the JVM default locale, which may
not be "M/d/yy".
And in the EntryBean.copyFrom, the date string generated for the
setDateString should use "MM/dd/yy". But again, the actually used df is
depending on the jvm's default locale. For example, in my environment, the
default locale is "zh_CN", and the date string generated for edit is
something like "07-6-30", which the CalendarPopup can not recognize.
Solution is very simple, since the CalendarPopup can only recognize the
"MM/dd/yy" format, hard code set the DateFormat using SimpleDateFormat
directly. I've attached a patch file for this.
Another little problem should be addressed is that even in the en_US default
locale environment, the original code generate date sting using "M/d/yy"
format, not "MM/dd/yy". Notice the slight difference will cause
CalendarPopup can't auto locate to the date when popup,if the month or day
value have only 1 digits.
http://www.nabble.com/file/p12088185/EntryBean.patch EntryBean.patch