I developed an application in ASP.NET with MS SQL on a US based server.
Once the app was deployed to a server somewhere in Europe the dates are displayed in Dutch format.
US application displays: March 6, 2018
European application displays: maart 6, 2018
The US Sql Server is 2012 and the European SQL Server is 2014.
I've compared the SQL Server settings and there is only one difference I can find...
US SQL Server Collation = SQL_Latin1_General_CP1251_CI_AS
Europe SQL Server Collation = SQL_Latin1_General_CP1_CI_AS
I don't believe collation is the issue because I changed my US based server to match the European collation and there was no change in date format.
In C# I display the dates like this...
Convert.ToDateTime(mySQLTable.Rows[0]["datecompleted"]).ToString("MMMM d, yyyy");
The data in field "datecompleted" (DateTime) is identical on both servers.
I compared the HTML source code of both applications (View Source) and they are identical.
I can't see any difference in IIS either.
Any ideas where I should look to determine why one server is displaying dates in Dutch and the other in English?
Thanks!
Thanks to Mark Benningfield this has been resolved...
I needed to add InvariantCulture to my C#
using System.Globalization;
...
Convert.ToDateTime(mySQLTable.Rows[0]["datecompleted"]).ToString("MMMM d, yyyy", CultureInfo.InvariantCulture);
Now my date displays properly!
Related
I am formatting a date for integration with Moneris' recurring billing. The request requires a start billing date formatted as "yyyy/MM/dd". Simple task and "it works in Dev".
When I publish the API code to our staging environment the submissions fails (with a very help-less error from Moneris, "System or data problem. Please try again."). I have determined that it is in fact the date format of the start date at issue.
In Dev, the output is as instructed above, however, in staging the output comes out formatted as "yyyy-MM-dd". This breaks the submission. I went so far as to hardcode a value with the correct format and it succeeded. So we know that the outputted format is the difference at issue.
I have not run into this issue with any other instance of ToString("blah") on a DateTime. Is it to do with a DateTimeOffset? Why would the formatting waiver from what was instructed?
The API is a C# Asp.NetCore 3 solution.
Development Enviro: Windows 10 Pro
Staging Environment: Windows Server 2019 Standard
In custom DateTime format strings, unescaped / represent the date separator, which is culture-specific. If the machine running your program is configured with en-US culture, then the separator is / as you'd expect. But ar-DZ uses -, tr-TR uses ., etc. (See here for more info.)
To ensure that the string is always formatted with / characters, you need to escape them:
date.ToString(#"yyyy\/MM\/dd")
or
date.ToString("yyyy'/'MM'/'dd")
I have a SQL Server 2012 table with a column named X and defined as DATE.
When I run GetOleDbSchemaTable(OleDbSchemaGuid.Columns,...) the DATE_TYPE comes up as 130. I was expecting 133.
Can anyone please explain? Many thanks!
From MSDN Using Date and Time Data:
Backward Compatibility for Down-level Clients
Some down-level clients do not support the time, date, datetime2 and
datetimeoffset data types added in SQL Server 2008. The following
table shows the type mapping between an up-level instance of SQL
Server 2008 and down-level clients.
You see the 130 because of backwards copatibility
In a web application, I am passing datetime without formatting it in a XML response, just item.Date (DateTime datatype) is put in code.
No formatting is done. When I run the local server it returns the date in MM/DD/YYYY format and in live environment DD/MM/YYYY. Why this change is happening?
I checked on database collation and OS settings. Live environment had English (Singapore) in regional settings. However after changing local servers to English (Singapore) still live environment DateTime format is not being produced locally.
Collation:
In Live Environment - Latin1_General_CI_AI
In Local Servers - SQL_Latin1_General_CP1_CI_AS
What could be the reason? how to resolve this rather than doing formatting in XML?
Update
As suspected, Issue is with collation, regenerated the issue locally after creating DB with collation in live environment.
Windows stores Date/Time settings per user. If IIS is running as LocalSystem, then you'll need to change the settings of the Default user:
In regedit, go here and set the appropriate values up for the locale and format that you want.
HKEY_USERS\.DEFAULT\Control Panel\International
That said, handling dates and times types under the assumption of any given format is A Really Bad Idea.
If you need date/time in a specific format for display, interop or whatever you should format the date time appropriately with one of the available string formats.
I'm working with MVC3 and Entity Framework. In my application I need to call a stored procedure in SQL Server 2005 via EF to search for some data according to datetime parameters passed.
Everything seems to be working fine in local environment. But after hosting it into IIS I am getting an exception while trying to search from date 13-08-2012 (13 is taking as month in SQL I guess)
Error says
SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM
I understood error is because of the difference between date time formats between System.Datetime and SqlDatetime.
But I didn't understand why it is working without any issues in my local environment which uses same SQL Server but getting this error after hosting in IIS server.
Is there any workaround for this issue?
My issue is resolved now. Issue was with the culture settings in IIS.
I've added these line to my applications web.config and it is working fine now.
<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="en-GB" uiCulture="en-GB"/>
For more information check out this Issue with culture settings in IIS
IT depends on the culture of the server, you can format your culture with invariant format, on your date 13-08-2012, it consider 13 as month.
//Here an example of formatting with invariant culture
CultureInfo yourCulture = CultureInfo.InvariantCulture;
yourValue.ToString("yourFormat",yourCulture));
Verify that the date time formatting. Also, DateTime doesn't have the same range as SqlDateTime. You'll run into trouble if you receive an empty value.
This has got me really flumoxed!
In the datalayer ADO.NET connects to SQL Server 2008, Default language for the login is 'british'
Selects a DateTime column into a dataview and returns it.
aspx page databinds
this: <%# String.Format("{0:MMM/yyyy}", Eval("dbPeriodFrom")) %>
The database returns 2009/10/01 (This is yyyy/MM/dd)
The result of step 4 is Jan2009 ????
The regional settings of the web server is United Kingdom
There is no <globalization... section in machine.config
The NET globalisation in IIS is set to uiCulture=en culture=en-GB
I even set it in the web.config for the site
This is a classic "Works on my dev machine.." But, borked when deployed to production scenario.
What could I possibly have missed?
EDIT
So it appears the login used by the ASP.NET Application to connect to SQl Server 2008 is getting a US datetime, even though in the properties for the login, the default language is set to 'British English'.
The problem occurs in TSQL:
SELECT
DATEPART(month, CAST('2009.02.01' AS DATETIME))
,DATEPART(month, CONVERT(DATETIME, '2009.02.01', 102))
OUTPUT for windows integrated login (Administrator) with default language set to 'English'
2 2
OUTPUT for SQL Server login used by ASP.NET with default language set to 'British English'
1 2
Check the locale setting on the database itself and on their server, depending on the set up, the date will be formatted accordingly to the locale setting. I suspect the database server is probably set up to US English - Poke around in the regional settings on the db server itself.
Hope this helps,
Best regards,
Tom.
I'd be interested in seeing the code where you get the date out of the command/reader/adapter - if the database column is typed as a datetime, then what comes over the wire isn't actually "2009/10/01" - it is a binary number (like most dates are on the wire). As such there is no ambiguity.
I expect that somewhere you are treating it as a string (perhaps some Parse) - this shouldn't be necessary. If it is, you aren't SELECTing it as a datetime, but as a [n][var]char(x).
Check value stored in database using Management Studio. Also in MS SQL server universal format of date is YYYY-MM-DDTHH:MM:SS.mmm (2009-01-05T10:12:55.001) and YYYYMMDD (20090105). Those formats parsed always the same, no matter which locale used by database.