[DynDasE]

Neep support about Locale Setting in Dojo’s Calendar

I’m currently developing a database service using Myeclipseforspring.
I need to change every year format into Thai year.(Buddhist year)
The problem is the dojo calendar thai locale setting is not working.
( Firefox show A.D. , and IE show 1468… )
Overmore, the style in dojo is locked in Spring 3.0.
I try using other doho style , but it’s not working with the generated dojo calendar.

I want to ask , if there any quick solution to this problem ? , before I change this gadget into other’s.

[jkennedy]

Just to verify, are you trying the approach that is covered here or some other approach? http://forum.springsource.org/showthread.php?t=86442

Thanks,
Jack

[DynDasE]

How can I lock the year format for each browser ?
I don’t each of the browser to display different year.
With Java approaching , where can I config the year format for database ?

[DynDasE]

In IE , the year keep on decreasing if we repeating edit then save any entity for several times , while other browser don’t.
How can I fix these ? This is very annoying.

[jkennedy]

I am not sure how to recreate this problem? I scaffolded an application that uses a Date and the DOJO calendar works correctly using IE.

Which version of IE are you using?

Thanks,
Jack

[DynDasE]

I’m using IE8 , with Thai Locale. DB2 9.0 as database.
In Thai , a database usually keeps date record in A.D. (ex. 2011) , but display in Thai’s. (ex. 2554)
In IE8 , a dateformat get the A.D. Year in the database , then IE8 doesn’t recognize that it is A.D. so the year is decreased.
When you click edit , the calendar will show a decreased date.
If we save , the DB will minus those year again as it usually process of Thai locale DB.

[jkennedy]

We are working for a resolution to this issue in ME4S 9.0.
While we are still investigating, it does appear that there could be situations where the Date that is parsed on the Server is incorrect in that the format that is being used is Locale specific, but the parsing routine does not “shift” the Date based on the variance between Gregorian and Thai Calendars (Years).

The code that is backing this process is org.apache.commons.lang.time.DateUtils.parseDate(text, String[] patterns) and while the patterns may be Locale specific, the Date that is returned is not “shifted” and so if the date comes in as 2554 it looks like it would be passed on to the DB as 2554 rather than being stored as 2011.

I believe we would see different results depending on the default locale of the App Server.
Can you tell me if the Locale of the App Server is also Thai.
Also, what is the Locale setting for the DB?

Thanks,
Jack

[DynDasE]

The Db2 config is ;

Database Configuration for Database MOC2

Database configuration release level = 0x0c00
Database release level = 0x0c00

Database territory = TH
Database code page = 1208
Database code set = UTF-8
Database country/region code = 66
Database collating sequence = IDENTITY
Alternate collating sequence (ALT_COLLATE) =
Number compatibility = OFF
Varchar2 compatibility = OFF
Database page size = 4096

The problem is I was commanded to store thai year (2554) in DB2 , which is broken in IE8.
If the DB2 store A.D. , using the program with Firefox/Chrome it’s working fine if I can store A.D. in my database.

Ex. ${current.datadate.time} is the code I used to show a date
Which will be Wed Jan 01 00:00:00 ICT 2549 <– Thai year
In Firefox and Chrome , put that code in formatdate Tag , the year will be 3092.
In IE8 , my tag is broken , the year shows the same. 2549
When users are going to save in Firefox/Chrome , the edit page will show 3092 , so saving won’t decreased.
But IE8 does.

One of the solution is store the same year as it shown on the page.
IE8 cannot show Thai year . When saving to the database , the year will be decreased.

Would you please teach me where can I use parseDate to prevent it for decreasing the year ?

P.S. The dojo calendar widget isn’t Thai year yet. I will use other Thai’s Calendar widget instead.

Thank you

[jkennedy]

Thank you for the detailed response.

The reason that IE is exhibiting a behavior that looks “wrong” is because it is the only browser that is sending an Accept-language header that includes both the location and the language. This combined header is enough to tip of the server to use the Buddhist Calendar object to manage dates rather than the Gregorian Calendar. The Buddhist calendar will take a java.util.Date object and shift the year up by the increment needed for the Buddhist Calendar. When the date is stored in the DB, it will be the Gregorian year, not the Buddhist year.

For Chrome and Firefox, they are only passing the “language” portion of the Accept-Language header and so the server side is using a Gregorian calendar “all the way through the process” and will store the Buddhist year of 2554 in the DB. While this may look correct to some users on some browsers, if you were to also have users who used Gregorian calendars they would see dates that looked to be many years in the future. For example, if you hooked a reporting tool up to your database etc.

And so you will need to decide whether the DB is storing years in the Gregorian “year” or the Buddhist year and then once you make your decision on that, change the UI to do what you like.

If you want to “disable” the servers ability to use the Buddhist calendar and simply pass the date through to the DB without it being changed, I would recommend that you write your own LocaleResolver and point Spring at that code to avoid resolving to a Locale that uses a Buddhist calendar when IE passes the AcceptLanguage header:

Here is more information on that subject:

The default Spring approach to resolving the Locale of the user is http://static.springsource.org/spring/docs/1.0.2/api/org/springframework/web/servlet/i18n/AcceptHeaderLocaleResolver.html

This resolver can be switched out by Registering your own LocaleResolver:
http://www.mkyong.com/spring-mvc/spring-mvc-internationalization-example/

If you want to customize your application at the lowest level where the Date Parsing happens prior to binding the date from the Web Layer to the Object model on the server side, you can register your own Calendar editor.

On your project, open the Type Chooser and look for this Type: org.skyway.spring.util.databinding.CustomCalendarEditor. You should be able to open the Source for this code because we package it and include it on your project. You can also find references in your project to where CustomCalendarEditor is applied. This Editor is used by Spring to bind the “text” that is coming back to the Web Server to the Calendar Object in your Domain Model (JPA Entity). You can walk through this code to see how our default implementation is doing its work.

Most of the real work is done in a class called org.skyway.common.util.date.DateParser.

Let me know if you have any further questions and also let me know which solution you wind up choosing.

Thanks,
Jack

[Author]

Posts