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")
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´m having the following error in my .Net application:
20170710-18:47:34.938 : Connection succeeded 20170710-18:47:34.940 :
Initiated logon request 20170710-18:47:35.012 : Verify failed: Could
not convert field: Could not convert string (20170710-18:47:34.979386)
to DateTime: String was not recognized as a valid DateTime.
I want my application to support microseconds, currently I can send a LogOn msg but when I get the response, my App is not able to process the message.
Actually, the received message doesn't appear in my Log nor does it trigger any of my events (FromAdmin, FromApp)
I've tried changing my Dictionary but I could not pull it off.
This was probably caused by a limitation in QuickFIXn which didn't used to support UTCTimeStamps with anything other than zero or three milliseconds.
This appears to have been fixed in March. (Though it still isn't quite inline with the protocol.)
You should be able to fix this by updating your version of QuickFIX.
This is fixed in QuickFix/N version 1.8. You can download it here. Sadly isn't on NuGet yet.
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
I have a winforms client application which is written in c# 4.0 that sends
a simple datatable (in a dataset) to the server , which is written in vb.net 4.0.
The datatable is sent through a web service.
both client and server are on the same computer.
This has been working fine for many years.
Now I get a strange behaviour with a datatable generated from a csv file.
Here it how it looks on the client side:
and here is the server side:
for some reason, the first row time has shifted from 2:55 AM to 03:55 in the server.
This results in a duplicate key. what's up with that?
one of the strangest bugs I've ancountered. would appreciate any help with this one -
thanks.
As suggested by #mikey,
the problem was that client used a local user account
whereas the server used the IIS acount.
One of those acounts was set to use daylightsaving time,
the other was not.
In my country, daylight saving time ended on march 29,
so this resulted in a conflict between server time and client time,
even though both were on the same computer.
Mikey , thanks again :)
I've got problems with special characters being inserted and displayed properly. It's an ASP.NET 3.5 application (C#) and the database is MySql.
If I try to insert a special character into the database using a console app I get an error back saying 'Incorrect string value: '\x81 etc'. If I try to display them it displays for example ü instead of ü.
It works on my local machine, and the only difference I can find (and most likely the root of the problem) is that collation_server is set to latin1_swedish_ci on my machine, utf8_general_ci on the dev server, and character_set_server is latin1 on my machine, utf8 on the dev server. (Everything else is set to utf8 on both machines.)
I thought utf8 was the best thing to use, so now I'm not sure if I should change the dev server to be the same as my local machine which works, i.e. use latin, or change my local machine to be the same as the dev server and look for another solution to the problem? Any thoughts?
Thanks,
Annelie
Set your connection string as follows:
"server=<server>;port=<port>;database=<db>;uid=<uid>;pwd=<password>;charset=utf8;"
Example:
"server=localhost;port=3306;database=mydb;uid=root;pwd=root;charset=utf8;"
(add charset=utf8 to it)