System.FormatException after update donet and ef core - c#

I got this strange error out of a sudden after updating from dotnet 6.0 to dotnet 7.0
and EF CORE from Version 12 to Version 13.
But even more strange is; if i debug it in my meshine, it works.
if i run this in a docker container on my synology NAS, i get this problem.
But it worked before the update.
Input:
<td>23.01.2023 16:20:58</td>
try to parse like this
Date = Convert.ToDateTime(columns[0].InnerHtml, new CultureInfo("de-DE")),
Time = Convert.ToDateTime(columns[0].InnerHtml, new CultureInfo("de-DE")).TimeOfDay
the actual error i got is:
System.FormatException: String '23.01.2023 16:20:58' was not recognized as a valid DateTime.
at System.Convert.ToDateTime(String value, IFormatProvider provider)
what could going on here?

Regardless of what you think the culture identifier of that file is (you seem to think it's German?), there is exactly one way to correctly parse a date from a string when you know what format it is: DateTime.[Try]ParseExact.
DateTime.ParseExact("23.01.2023 16:20:58", "dd.MM.yyyy HH:mm:ss", null)

Related

c# SMO Backup - how to use ExpirationDate?

I followed roughly this example to backup a database with Microsofts SMO API and the code crashed with an exception telling invalid parameter ExpirationDate. I checked the documentation which does not contain details on how to set the parameter and my intuition told me it should be in the future, right? I was curious and tested some values:
DateTime.Today.AddDays(10) -> InvalidDataException
DateTime.Today.AddDays(-10) -> works fine
DateTime.Today.AddDays(-5) -> works fine
DateTime.Today.AddDays(-4) -> works fine
DateTime.Today.AddDays(-3) -> InvalidDataException
DateTime.Today.AddDays(-1) -> InvalidDataException
DateTime.Today.AddDays(100) -> InvalidDataException
DateTime.Today.AddDays(500) -> InvalidDataException
DateTime.Today.AddDays(1000) -> works fine
Reading this 5 year-old post it could be that the internal parameter is actually not of the type DateTime? But then it would be a bug, right?
These errors are likely the result of the locale of where the Backup.ExpirationDate property is being set from. Depending on the culture this is being executed in, the DateTime.AddDays method may increment the month instead of the day as expected, leading to the inconsistent results you saw. Of the values that you tested only the negative ones should cause errors, as the range of days for a backup expiration date is 0 - 99999, with 0 indicating that the backup will never expire as stated in the documentation. Try using the CultureInfo class to define a new locale then set the expiration date. This will require a reference to the System.Globalization namespace. Running the following code gave me no errors in setting the expiration date in a backup operation using the US (en-US) culture. Just make sure that the date in the culture you convert this to matches the date you expect it to in your timezone.
using System.Globalization;
string folderPath = #"C:\YourFolder\";
Server serv = new Server(#"YourServer");
Backup bkup = new Backup();
bkup.Database = "YourDatabase";
string bkupFilePath = folderPath + bkup.Database.ToString() + ".bak";
bkup.Action = BackupActionType.Database;
bkup.Devices.AddDevice(bkupFilePath, DeviceType.File);
bkup.BackupSetName = "YourDatabase Full Backup";
bkup.BackupSetDescription = "Full backup of YourDatabase";
DateTime today = DateTime.Now;
//define current date representation with en-US culture
string newLocale = today.ToString(new CultureInfo("en-US"));
//set Backup.ExpirationDate to use new culture
bkup.ExpirationDate = Convert.ToDateTime(newLocale);
bkup.ExpirationDate.AddDays(10);
bkup.ExpirationDate.AddDays(100);
bkup.ExpirationDate.AddDays(500);
bkup.ExpirationDate.AddDays(1000);
bkup.SqlBackup(serv);
edit I am super confused. I thought this solved my issue:
My issue was that I called backup.ExpirationDate.AddDays(X) without assigning it to anything. Therefore, the software was basically using "DateTime.Now".
Solution:
backup.ExpirationDate = backup.ExpirationDate.AddDays(X);
But it didn't completely. I still get the exception if I do this:
backup.ExpirationDate = backup.ExpirationDate.AddDays(1);
No idea why this code is wrong.

DateTime.Parse works in c# console app but not asp.net

I have written a C# console application that after all of it's processing outputs a DateTime to disk. It does this like so:
writer.WriteLine(myDateTime).
This same console appication has no problems with using the following to read this DateTime back:
DateTime.Parse(reader.ReadLine())
However, upon attempting to use the following code in my separate Asp.Net program I recieve an error saying that my string is not a valid DateTime which is odd to say the least.
StreamReader reader = new StreamReader(#"D:\InformerReports\Archive\ReliabilityData\StartTime.hist");
string dateString = reader.ReadLine();
return DateTime.Parse(dateString);
I have checked and the string it is reading in is 10/25/2016 12:00:00 AM.
I have also attempted to use return DateTime.ParseExact(dateString, "dd/MM/yyyy hh:mm:ss tt",null) but this returns the same error.
I can't seem to fathom why identical code performed on the same file works in one case and not the other. I'd appreciate some help.
I guess the culture of the server is different from the machine you are testing from.
The correct format you have to use seems to be:
return DateTime.ParseExact(dateString, "MM/dd/yyyy hh:mm:ss tt", null)
// 10/25/2016 12:00:00 AM
As an add-on to the previous answers.
To avoid the differing cultures across clients you can set the site culture in the global.asax files Application_BeginRequest method like below:
Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("fr-FR");
Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("fr-FR");
This will force the above specified culture for each user accessing the site.
I am not sure if there are drawbacks to doing it this way, but this solved my issue in the past.

DateTimeFormat.AbbreviatedMonthNames adding a dot at the end of month's name

Last night we migrated our web services tier from physical Windows 2008 r2 to virtual Windows 2012.
We are getting tons of events on ours logs about DateTime's invalid formats, strange as we double checked our regional settings.
Long story short:
CultureInfo.GetCultureInfo("es-MX").DateTimeFormat.AbbreviatedMonthNames
Outputs (using LinqPad5):
ene.
feb.
mar.
on our new 2012 env while on 2008 ouptus:
ene
feb
mar
Our parsing is something like this:
DateTime.Parse("18 ene 16",CultureInfo.GetCultureInfo("es-MX"))
And while it worked wonders now it throws
FormatException :
The string was not recognized as a valid DateTime. There is an unknown word starting at index 3..
While
DateTime.Parse("18 ene. 16",CultureInfo.GetCultureInfo("es-MX"))
works but isn't the expected input from our several clients.
Working on the same runtime version (4.0.30319.42000), double checked (again) our regional settings on both servers what else can I look for to fix this (before giving up and hacking it with a regex replace)?
Thanks.
Sadly I couldn't find anything in the configuration that pointed me in the right direction.
Ended with a nasty hack like this:
var cultura = CultureInfo.CreateSpecificCulture("es-MX");
if (cultura.DateTimeFormat.AbbreviatedMonthNames.First().EndsWith("."))
cultura.DateTimeFormat.AbbreviatedMonthNames = cultura.DateTimeFormat.AbbreviatedMonthNames.Select(c => c.Substring(0, c.Length > 1 ? c.Length - 1 : 0)).ToArray();
and used that culture in the parsing.
I ran into the same problem, when scraping a web-element for a date.
The date looked like this "Fre 14. okt 2022".
Inspired by DSXP answer, I found this to be working:
var cultureInfo = new CultureInfo("da-DK");
cultureInfo.DateTimeFormat.AbbreviatedMonthNames = cultureInfo.DateTimeFormat.AbbreviatedMonthNames
.Select(x => x.EndsWith(".") ? x.TrimEnd('.') : x)
.ToArray();

Cannot deserialize datetime property Neo4j using C# client in a transaction

My problem is related to this question:
I'm having the same failure, but in a different scenario:
At run time the error is occurring inside;
using (var scope = new TransactionScope())
{
// Doing stuff here fails only within a transaction!
scope.Complete();
}
The same problem code runs perfectly fine when executed outside of a transaction!
The error message is:
Newtonsoft.Json.JsonReaderException was unhandled
HResult=-2146233088 LineNumber=1 LinePosition=33 Message=Could
not convert string to DateTime: 15/05/2016 09:23:34 +00:00. Path 'a',
line 1, position 33. Path=a Source=Neo4jClient
The code versions are:
Neo4jClient version=1.1.0.16
Newtonsoft.Json version=8.0.1
This answer basically says I can pass a
new IsoDateTimeConverter { DateTimeFormat = "dd/MM/yyyy" }
To the serialisation but as that is inside Neo4jClient how can I implement that.
Answer
client.JsonConverters.Add( new IsoDateTimeConverter() );
Adding this line of code immediately after creating the client, solved the of datetime serialisation problem.
Note: my culture is en-GB so I am not sure if this would need finegling to adjust for your culture settings.
client.JsonConverters.Add( new IsoDateTimeConverter() );
I think there are numerous ways of making this happen but this one definately works.

DateTime parsed differently in different environments?

I am inserting some data into a SharePoint list (via web services) and on my local machine I set a date field like this (hard coded in this example)
<Field Name='TimeOnScene'>" + DateTime.Parse("13/12/2011 1:00").ToString("yyyy-MM-ddTHH:mm:ssZ") + "</Field>
and it works fine on my local machine, but if I publish it to our web host and run the exact same code I get
{"Message":"String was not recognized as a valid DateTime.","StackTrace":"
//
//
System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)\r\n at System.DateTime.Parse(String s)\r\n "ExceptionType":"System.FormatException"}
How is this possible?
Thanks in advance.
Edit:
we also moved from host to another two weeks ago and never had this issue before.
Use DateTime.ParseExact instead of Parse, the converting will be like the following code.
CurDate = DateTime.ParseExact(YourDateString, "dd/MM/yyyy hh:mm", System.Globalization.CultureInfo.CurrentCulture, System.Globalization.DateTimeStyles.None)
The host could have different local in set on there machine. in the documentation
The string s is parsed using formatting information in the current DateTimeFormatInfo object, which is supplied implicitly by the current thread culture.

Categories