1

I am converting DateTime using this code

DateTime d2;
bool success = DateTime.TryParse(String.Format("{0:dd/MM/yyyy}", row["Remarks"].ToString().Trim()), out d2);
if (success) row["PublishedOn"] = String.Format("{0:dd/MM/yyyy}", d2);

but when i convert 23/02/2015 or dd greater than 12 it fails because it always take format as "MM/dd/yyyy".

How can I convert "dd/MM/yyyy" from a string to a DateTime?

Wai Ha Lee
  • 8,598
  • 83
  • 57
  • 92
zulqarnainjalil
  • 157
  • 1
  • 11
  • 2
    `String.Format("{0:dd/MM/yyyy}", row["Remarks"].ToString().Trim())` wat? – Albireo Dec 15 '15 at 10:59
  • 2
    What's the type of `row["Remarks"]`? – Albireo Dec 15 '15 at 10:59
  • 3
    I strongly suspect you don't need to format and parse at all. Any time you find yourself doing that, you should question whether you *really* need to. – Jon Skeet Dec 15 '15 at 11:00
  • 1
    It has been answered a very similar question here: [http://stackoverflow.com/a/15738613/5287860](http://stackoverflow.com/a/15738613/5287860) – Nodiink Dec 15 '15 at 11:02

2 Answers2

6

You can use DateTime.ParseExact/TryParseExact and pass the format you want to use:

var date = DateTime.ParseExact("23/02/2015", "dd/MM/yyyy", CultureInfo.InvariantCulture);
Jakub Lortz
  • 14,616
  • 3
  • 25
  • 39
  • [`DateTime.TryParseExact`](https://msdn.microsoft.com/en-us/library/ms131044.aspx) would be a more robust efficient alternative. – Albireo Dec 15 '15 at 11:00
  • @Albireo not really - the difference between the two methods is in how they treat failures. Nothing makes one or the other more robust - one could even argue that `ParseExact` is more robust because it doesn't let you ignore failures – Panagiotis Kanavos Dec 15 '15 at 11:02
  • @PanagiotisKanavos I used a wrong term, it should have been "efficient", not "robust". Throwing an exception if the value is not a date is bad for performance. – Albireo Dec 15 '15 at 11:04
  • @Albireo that would also be wrong - `ParseExact` calls `TryParseExact` internally. Throwing an exception is **not** bad for performance just like a blown fuse isn't bad for electrical consumption. If you *don't* want to allow bad data ever, using `TryParseExact` is what will hurt performance and be riskier too – Panagiotis Kanavos Dec 15 '15 at 11:07
  • @PanagiotisKanavos performance considerations aside, [exceptions are not meant for flow control](http://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx). Claiming `TryParseExact` is more dangerous than `ParseExact` because the developer must check the outcome is condescending, it's our job as developers to handle error conditions. (You'd *really* let an `ArgumentException` leak outside your method for something unrelated to a parameter of the method?) By the way, if as you said `ParseExact` internally calls `TryParseExact`, then `TryParseExact` *can't* be slower than `ParseExact`. – Albireo Dec 15 '15 at 11:22
  • @Albireo - in this case, you could argue that an incorrect date isn't the "normal" flow, so exceptions are an acceptable option. Really it just depends on how you want to do the error checking/handling... If your preference is to do the check, do that, but other people will do it differently. – kͩeͣmͮpͥ ͩ Dec 15 '15 at 11:25
2

DateTime.ParseExact or DateTime.TryParseExact are what you want

kͩeͣmͮpͥ ͩ
  • 7,783
  • 26
  • 40
  • I already have use both of them but my problem is not resolving using these – zulqarnainjalil Dec 15 '15 at 10:58
  • 1
    How have you used them? – kͩeͣmͮpͥ ͩ Dec 15 '15 at 10:59
  • 1
    @zulqarnainjalil if you want to parse text, these methods are what you have to use. If there is an error, check the pattern you've used. Most likely you passed the wrong pattern. Or you actually tried to parse what is already a date value - why do you *format* the value in the first place? – Panagiotis Kanavos Dec 15 '15 at 11:03
  • I was using 'DateTime.ParseExact(row["Remarks"].ToString().Trim(), "dd/MM/yyyy", CultureInfo.InvariantCulture)' – zulqarnainjalil Dec 15 '15 at 11:05
  • but when i use 'DateTime.ParseExact(row["Remarks"].ToString().Trim(), "dd/MM/yyyy", CultureInfo.InvariantCulture).Date.Day' I got my answer – zulqarnainjalil Dec 15 '15 at 11:06
  • @zulqarnainjalil the code you just posted has nothing to do with the question - instead of parsing, you try to extract a specific date component. That's not what you asked at all. In fact, the parsing call is the same in both cases – Panagiotis Kanavos Dec 15 '15 at 11:10
  • @ PanagiotisKanavos Tryparse is parsing the values but not dd greater than 12. i think Tryparse is assuming dd as MM and MM can not be greatet than 12 – zulqarnainjalil Dec 15 '15 at 11:12