Convert Date from 6/05/2020 format to dd/MM/YYYY format

DateTime doesn't store dates in any specific format - it uses an internal representation (what exactly shouldn't matter).

After parsing the string to a DateTime, there is no inherent format there. There is only a format when you output the value. What you see in the debugger is simply a conversion to a string using your system settings.

If you want to format the DateTime, use ToString with a format string:

dt.ToString("dd/MM/yyyy");

The converse also applies - if you need to parse the string unambiguously, use ParseExact or TryParseExact (both static members of of DateTime):

DateTime dt;

if(DateTime.TryParseExact(txtDate.Text, "dd/MM/yyyy", CultureInfo.InvariantCulture,
                           DateTimeStyles.None, out td))
{
  // Valid date used in `txtDate.Text`, use dt now.
}

Read about custom and standard Date and Time format strings.

EDIT: This value: "11/2/2010" doesn't match the format "dd/MM/yyyy". It matches the format "d/M/yyyy" - for "dd/MM/yyyy" it should be "11/02/2010".

That's why TryParseExact is failing for you. You need to pick the right format pattern.

---

A DateTime value doesn't have a format. It just represents date and time (in the ISO calendar, and possibly in different time zones, but that's a different matter). It's like an int - it doesn't represent "a decimal integer" or "a hex integer" - it's just an integer within a particular range. You can format a number as decimal or hex, but it doesn't inherently have a format.

It sounds like you should parse it with ParseExact to specify the format when converting from the textbox, or probably TryParseExact:

// This is assuming you're absolutely sure of the format used. This is *not*
// necessarily the user's preferred format. You should think about where your
// data is coming from.
DateTime date;
if (DateTime.TryParseExact(text, "dd/MM/yyyy", CultureInfo.InvariantCulture,
                           DateTimeStyles.None, out date))
{
    // Okay, successful parse. We now have the date. Use it, avoiding formatting
    // it back to a string for as long as possible.
}

You should keep that value as DateTime for all purposes except giving it back to a user - at which point you may well want to use their cultural settings.

In particular, if you're storing the value in a database you should not convert it to text and include it in a SQL statement - that's asking for trouble. Instead, use a parameterized SQL statement and set it as the parameter value, still as a DateTime.

In order to avoid any error on months / days when parsing a date, it is probably better to use DateTime.Parse or DateTime.ParseExact than ToDateTime.

As this thread and this article pointed out.