-1

I'm moving all my info and projects from Win7 to Win8 when suddenly an unexpected error appears with the datepicker Uncaught Unexpected literal at position 2.

I set the CurrentCulture to es-VE like this: System.Threading.Thread.CurrentThread.CurrentCulture = New CultureInfo("es-VE")

On my debugging process I found that the problem is my CultureInfo.CurrentCulture.DateTimeFormat

Win7 sets it like this: enter image description here

Win8 sets it like this: enter image description here

As you can see the dateSeparator changes and that's throwing the Javascript exception cause its expecting dd/mm/yyyy instead of dd-mm-yyyy

Any ideas on how to solve this?

Is it a bug from Microsoft?

Am I doing something wrong?

Thanks in advance!

Update: Control Panel, settings are the same on both machines.

enter image description here

Luis
  • 5,786
  • 8
  • 43
  • 62
  • can you check the control panel? – Daniel A. White Jul 24 '14 at 16:02
  • @DanielA.White its the same on both machines, it would not matter if I'm forcing the setting. – Luis Jul 24 '14 at 16:07
  • Why the downvote? I'll will be nice to know the reason... – Luis Jul 24 '14 at 16:08
  • please share your javascript side. maybe something can be improved. – Daniel A. White Jul 24 '14 at 16:10
  • Anytime you pass a date as a string to JavaScript, you should use a [custom format specifier](http://msdn.microsoft.com/en-us/library/8kb3ddd4(v=vs.110).aspx) instead of the [culture specific ones](http://msdn.microsoft.com/en-us/library/az4se3k1(v=vs.110).aspx). Then things are less likely to break due to culture settings. When you show dates to users, use culture settings. When you're passing dates in code, use invariant culture and/or custom format. – mason Jul 24 '14 at 16:13
  • @DanielA.White i think the problem is on the backend not on the javascript, I found the error thanks to the JS, yes it can be fixed if I do some fixes, but I think its not the idea to touch the JS. – Luis Jul 24 '14 at 16:18
  • @mason this is a web service, today is consumed by a JS, tomorrow could be something else. I think the problem should be fixed on the backend. I agree by using a `custom format specifier`, by why if I use the same culture `es-VE` I got different date separator values? – Luis Jul 24 '14 at 16:21
  • There have been a lot of changes in Venezuela, Microsoft just follows whatever direction the political wind is blowing. Your Control Panel view is for your local culture, you'd have to change the machine's locale to see the overrides that are effective for es-VE. Use superuser.com to ask questions about this. – Hans Passant Jul 24 '14 at 16:31
  • @HansPassant ok, I thought it was more of a related question to the Framework instead of the OS. But you practically answer my question about the `CultureInfo` class due to the political changes in Venezuela, the fact is that all the dates are still being shown as `dd/MM/yyyy` (including newspapers and government web pages) idk where did Microsoft found info about that change, but I guess they have thier sources... Thx – Luis Jul 24 '14 at 16:47

1 Answers1

0

We make changes to data as we are made aware of better data that is available. You should never assume that the data will be the same. Best practice then is to ensure that any persisted data is stored or transferred using a standard format (ISO 8601 for dates). Localized data should be ephemeral.

By the way, the control panel settings only allow overrides for the user locale but if the user locale happens to be the culture that in question, you can make changes (one more reason why applications should not make assumptions about the data not changing).

Eric MSFT
  • 3,246
  • 1
  • 18
  • 28