Duplicated by using JSP + JSF 1.2 + trunk ICEfaces (post 1.7 DR2) on JBoss 4.2.1. My web browser was configured to send "fr-FR,fr;q=0.9,en-us;q=0.7,en;q=0.6,fr-fr;q=0.4" as my Accept-Language request header, and my faces-config.xml had:
<locale-config>
<default-locale>fr_CA</default-locale>
<supported-locale>fr_CA</supported-locale>
</locale-config>
What happens is that when the UIViewRoot does not have a specific Locale set in it, UIViewRoot.getLocale() delegates to ViewHandler.calculateLocale(FacesContext) for selecting the Locale, based on the faces-config.xml's locale-config section, and the web browser's Accept-Language request header.
On the initial page load, calculateLocale will select one of the latter locales specified in the Accept-Language request header, which has higher precedence in the faces-config.xml's locale-config section's list of supported-locale entries. On the post-pack, from the first Ajax interaction, the JSF RI 1.2 code in com.sun.faces.lifecycle.RestoreViewPhase.execute(FacesContext) will simply grab the first locale in the Accept-Language request header, and set that in the UIViewRoot. This locale may have a different starting day of the week, or any other number of differences from the previously used locale. In my tests, it was going from fr-CA to fr-FR that exhibited that difference. My browser was configured to prefer fr-FR, and calculateLocale saw that fr-CA was the most compatible supported-locale. But on the second lifecycle it just stomped fr-FR in, regardless of the configured supported-locale entries.
That code path in RestoreViewPhase.execute only happens with ICEfaces + JSP + JSF 1.2, because we keep our component tree, instead of rebuilding it each lifecycle. So, in theory we could change that, but it would be quite an undertaking.
The simplest solution is for the user to simply add a <supported-locale>fr_FR</supported-locale> entry to their faces-confg.xml, so that French users from France will get that locale on their first lifecycle, and when it stomps fr-FR into the UIViewRoot, they'll just be continuing to use the same locale.
But, to take the burden off of developers, what might be a more elegant approach, would be to render out the UIViewRoot's current locale, and have the bridge code in the browser set that as the first locale in its Accept-Language request header, so that it will always be specifying to continue using whatever locale the server has just served out.
Following behaviour seen with Icefaces1.6.2:
When the page is loaded the first time the week starts with"dim" but when some date in the current month is selected the starting day of the week changes to "lun".