it is a web page (Asp.Net MVC), multi-language including english, latvian, lithuvian, russian, polonia.
For selecting a date we choose the jQuery-Ui-datepicker including extra localization files for each language. (Date is given as string: "DateTime".ToString("d", new CultureInfo("lv")) )
All runs fine with all languages at my development computer (Win10, DotNet 4.5, Visual Studio 2012).
Running the web application at the server (Windows Server 2012 R2) other languages without problems. But the latvian language leads to problems.
I added trace code around the CultureInfo for Latvian 'lv'.
There is an difference between the CultureInfo.DateTimeFormat.ShortDatePattern between development notebook and web Server.
CultureInfo.DateTimeFormat.ShortDatePattern
- my computer: 'dd.MM.yyyy'
- web server : 'dd.MM.yyyy.'
the fastest solution would be: trim final point at datetime format.
(the javascript seems to work without the 'final point')
Is it a Framework Bug ?
which system needs a fix ? the server or my computer (inclusing javascript datepicker localization source)
How to solve it in a nice way (so it doesnt seems hacky)
thanks,
Mathias
Related
I have an old and heavy windows application where DateTime.TryParse(string value, out result) is used extensively.
The below code runs smoothly on Windows 7 and Windows 10.
// Below is done when the application starts
System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-AU");
var success = DateTime.TryParse("20 02", out result);
// Above is just an example of one of the ways we have been using it. Here success is true and results are -> 20/02/2020 12:00:00 AM
But above statement returns false when executed on Windows Server 2012 R2 Standard.
Appears like Win Server 2012 has broken the
DateTime.TryParse. Interestingly if I use .netFramework 3.5 then it works in all OS. But we are on framework v4.6.2 (VS-2019).
Is this a bug in Microsoft OS or .netFramework 4.6? Is there any existing workaround for this without making any changes in code, maybe a .net framework patch, etc. Honestly, it will be difficult for me to make any changes in code related to this as its usage is more than 1.5k in the application.
Thanks in advance !!!
Maybe not the answer, but can you try this on your Windows Server 2012 R2.
foreach (var ci in CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures).OrderBy(ci => ci.Name))
{
Console.WriteLine("{0} ({1})", ci.Name, ci.EnglishName);
}
are you culture part of that list?
Read this: https://learn.microsoft.com/en-gb/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c
Or do this: https://learn.microsoft.com/en-us/archive/blogs/shawnste/locale-builder-v2-0-for-windows-8-1server-2012-r2-released
I recently started having a problem with CultureInfo in my web application.
The code in question:
public static CultureInfo ConvertToCultureInfo(this string input)
{
try
{
return new CultureInfo(input);
}
catch (Exception)
{
return new CultureInfo("en-US");
}
}
When a user whose locale is 'en-AT' is accessing my website the request for this cultureinfo works on my local but is failing on my Windows Server 2012 box (and falling back to en-US, which is incorrect).
We tracked it down to an issue with the MS-LCID version 10.1 but this is allegedly only available for Windows Server 2016.
However, this occurs to me as kind of silly - why can't we just download a package that updates the existing LCID to support the newer locales? It's still the same list of dateformats and Windows Server 2012 is still supported. I can't find any resources on updating this and was hoping someone here knew a bit about this and could point me in the right direction.
Right now my best lead is to additionally test for custom CultureInfos and supply my own formats, but this seems like overkill when there exists the LCID, it's just somewhat out of date.
I'm working with two servers (Server 2012 Std) and (Server 2016).
On 2012 when I run the command:
[System.DateTime]::UtcNow.ToString([System.Globalization.CultureInfo]::GetCultureInfo("en-NZ"))
I get back the result:
13/03/2018 12:49:55 a.m.
When I run the same command as above on my Server 2016 I get back:
13/03/2018 12:48:42 AM
They key part is the AM/PM formatting. I'm trying to understand why these are returning different results and how to get the server 2016 output to be formatted the same as the first. This is due to an application requirement and I do not have access to change the application to format the string so I have to resolve this at the OS level somehow.
Take a look at Output of times (AM/PM) changed in Windows 10 when using DateTime.ToString("tt") for some discussion of this.
It doesn't appear that you will be able to fix this without changing application code.
I found the same problem and I was able to get around the issue by using the following code. Not sure if that's what your looking for.
[System.DateTime]::UtcNow.ToString("dd/MM/yyyy hh:mm:ss tt")
I have a web application in which I set the CultureInfo on Thread.CurrentThread to ar-IL (Arabic-Israel):
Thread.CurrentThread.CurrentCulture = new CultureInfo("ar-IL")
The problem is that on my local machine (Windows 10 with IIS 10) it works just fine and no exception is being thrown. However, on Azure (Windows Server 2012 R2 with IIS 8.5) it throws CultureNotFoundException:
Culture is not supported. Parameter name: name 'ar-IL' is an invalid
culture identifier
I checked the source of CultureInfo and realized that the native call to nativeInitCultureData() is the culprit. On my Windows 10 machine it returns true but on Windows Server 2012 it returns false.
Also, checking the SSCLI for nlsinfo.cpp file reveals this comment:
// Call GetLocaleInfoEx and see if the OS knows about it.
// Note that GetLocaleInfoEx has variations:
// * Pre-Vista it fails and has to go downlevel
// * Vista succeeds, but not for neutrals
// * Win7 succeeds for all locales.
// * Mac does ???
So, how can I handle custom combinations of languages and regions (ar-IL, he-US etc) that are not recognized by Windows?
P.S I'm aware of the possibility to create and register a custom locale (using CultureAndRegionInfoBuilder) but it will take too much effort to cater for all the combinations I'm planning to support.
Yes, Windows 10 is able to provide somewhat sensible information for any culture name.
Constructing culture info yourself is an option - as long as calendar information is compatible you can merge strings from neutral ("HE") culture with data for any specific one (like "en-US"). CultureAndRegionInfoBuilder can be used to safely combine information as shown in the MSDN sample:
// Create a custom culture for ru-US.
CultureAndRegionInfoBuilder car1 = new CultureAndRegionInfoBuilder("ru-US",
CultureAndRegionModifiers.None);
car1.LoadDataFromCultureInfo(CultureInfo.CreateSpecificCulture("ru-RU"));
car1.LoadDataFromRegionInfo(new RegionInfo("en-US"));
Aleternatively you can build XML files defining cultures you need to support and either load them at run-time or even install on the servers using CultureAndRegionInfoBuilder.Register - Create custom culture in ASP.NET.
When I'm using DateTime in dd-MM-yyyy format.
When I debug my code at localhost its works fine.
But After deploying my ASP.NET web project on IIS server DateTime changes to mm-dd-yyyy format automatically.I'm facing many issues because of this problem.
I'm not able to find any solution, please let me know how can I solve this.
How can I get rid of this issue.?
1) Change the datetime format of your server from:
Control Panel -> Regional and Language Options -> Advanced
2) Open IIS and follow below steps: (For IIS7)
Click on you Website
Select .NET GLOBALIZATION option
From Culture tab, select required Culture and UI Culture.
Finally iisreset.
Your IIS probably has another Localization selected, than on your development machine.
Printing should be pretty simple if you specify the format: yourDate.ToString("dd.MM.yyyy");
Parsing a date has been a problem for me in the past. You can change the server settings or specify a CultureInfo directly in the code, like this:
DateTime.ParseExact(myDateString, "yyyyMMdd", CultureInfo.InvariantCulture, DateTimeStyles.None);