I dont know how TryParseExact method works in a sample date format: This is the format: (Beginning: 2019.06.30. 14:56:43) And how to tell to TryParseExact this format?
-
1**[DateTime.TryParseExact Method](https://learn.microsoft.com/en-us/dotnet/api/system.datetime.tryparseexact?view=netframework-4.8)** – Ňɏssa Pøngjǣrdenlarp Oct 08 '19 at 18:58
-
1Didn't this get covered in that other question about your data in MySQL? – Caius Jard Oct 08 '19 at 18:58
-
Look at the documentation, find the format strings you need, and put it all together; and come back here with a more specific question. – Oct 08 '19 at 18:58
1 Answers
Per a mixture of a couple of answers in your other question I recommend you use a regex to strip out all non numerical then parse what remains:
var fromStr="Beginning: 2019.06.30. 14:56:43";
//strip non numerics
fromStr = Regex.Replace(fromStr, @"[^0-9]", "");
//now our dates of [2019. 09. 23. 14:54:23], [2019.09.23 14:54:23] or [2019-09-23 14:54:23]
//just become 20190923145423
if(DateTime.TryParseExact(fromStr, "yyyyMMddHHmmss", CultureInfo.InvariantCulture, null, out var fromDt)
//code if success
else
//code if fail
The docs and examples are here
I advocate cleaning your data up a bit because your formerly advised that your date time could appear as all pets of wacky and wonderful formats with random text around the place
I've added another answer here because TryParseExact wasn't specifically mentioned in those other answers, but its existence/use was probably implied - this question was specific and different enough to those to warrant a direct answer IMHO but it would be good if, as part of your "SO life", when you ask one question that leads to another question that you refer to the former question in your latter one - it gives those answering some helpful background context to the current question and allows you to clearly define how the new question is different to the previous one if you think it is
I'll also reiterate my previous advice that you really should be storing these DateTimes are DateTimes rather than variously formatted strings. If you're parsing logging output then it's understandable, but try I get it on the way into the db rather than on the way out

- 72,509
- 5
- 49
- 80