I was trying to validate a date read from app.config file using DateTime.TryParse() method. However, it returned true when the input was "12/05/201". This was actually a typo, and should have been, "12/05/2018". When I stepped through the code it automatically converted the date to "12/05/0201" and returned true. However when I used DateTime.TryParseExact(), it correctly returned false for the above input. So, should we always use DateTime.TryParseExact()? I am little confused because earlier I used use DateTime.TryParse() whenever I had to validate a date string! Both the code is given below:
Boolean isValidStartDate = DateTime.TryParse(startDate, out DateTime startDateVerified);
CultureInfo enUS = new CultureInfo("en-US");
Boolean isValidStartDate = DateTime.TryParseExact(startDate,"MM/dd/yyyy",enUS, DateTimeStyles.None, out DateTime startDateVerified);
Thanks
The year 201 being invalid is business logic - if you want to have logical safeguards on your imported data (and you should), do them explicitly. With C# you can easily add an extension method to DateTime if you want, something like
public static DateTime ParseDateWithSanity(this DateTime, string date)
{
dt = DateTime.Parse(date);
if dt.Year < 1900
{
throw BadInputException()
}
}
Best way to Validate date depends upon the use case and input data source and its formate
DateTime.TryParse is parsed using formatting information in the current DateTimeFormatInfo object so let's say if you use TryParse "12/05/201" it will return the parsed data according to your current culture settings. Which is "12/05/0201" ie in date format "MM/DD/YYYY"
Its always good practice to specify date formate and culture variance while parsing date and use TryParseExact instead of TryParse
(Note: To know about current culture settings you can look for a member of classes CultureInfo.DefaultThreadCurrentCulture and CultureInfo.DefaultThreadCurrentUICulture)
Related
I am using DateTime.TryParse method in my program to judge if a string value is DateTime, then I notice this:
DateTime.TryParse("9.08", out DateTime dt)
// true
DateTime.TryParse("2.52", out DateTime dt)
// false
Why would this happened ?
DateTime.TryParse is parsed information in the current DateTimeFormatInfo object, which is supplied implicitly by the current thread culture.
Because the DateTime.TryParse(String, DateTime) method tries to parse the string representation of a date and time using the formatting rules of the current culture, trying to parse a particular string across different cultures can either fail or return different results. If a specific date and time format will be parsed across different locales
In some cultures, DateTime separator is . rather than /.
On my computer.
DateTime.TryParse will Parse "9.08" be this year '09/08', 2018/09/08 is a valid datetime, so it's true.
DateTime.TryParse will Parse "2.52" be this year '02/52', but there isn't 52nd days on February, 2018/02/52 isn't a valid DateTime, so it will be false.
I would use DateTime.TryParseExact to Parse DateTime because you can set your CultureInfo and Parse DateTime string be parameters and ensure that conforms to your expected format.
DateTime.TryParseExact("09.08",
"MM.dd",
System.Globalization.CultureInfo.InvariantCulture,
System.Globalization.DateTimeStyles.None,
out dt);
As per DateTime.TryParse documentation:
returns a value that indicates whether the conversion succeeded.
As it couldn't parse "2.52" to any valid date, it returned false.
Except you are trying to understand every time string conversion of .NET
Otherwise, you should not able to answer "why exactly would that happened?"
DateTime.TryParse is just a simple condition handling to prevent you getting an error when you do
Convert.ToDateTime(dateString)
Thus, DateTime.TryParse = false means you should not do Convert.ToDateTime to that string.
Oppositely, if a string to DateTime.TryParse = true, then it means that string should match the expectation of .NET date string (it means .NET know how to convert that string to DateTime).
I have date string in format dd-MMM-yyyy and want to convert this to datetime, when I use below code
DateTime.ParseExact("20-Oct-2012", "yyyy-MM-dd HH:mm tt", null)
it causing an error
String was not recognized as a valid DateTime.
When I modify above code
DateTime.ParseExact("20-Oct-2012", "dd-MMM-yyyy", null)
then I got date time in format (mm/dd/yyyy) : 10/20/2012 12:00:00 AM
But I need it should be converted in yyyy/mm/dd format. Please help me in this regard.
You should try this
DateTime.ParseExact("20-Oct-2012", "dd-MMM-yyyy", null).ToString("yyyy/mm/dd")
For further reading on formats Check This
You need to distinguish between two separate concerns: that of parsing your original string into an abstract DateTime representation, and that of converting the latter back into another string representation.
In your code, you're only tackling the former, and relying on the implicit ToString() method call (which uses the system's current locale) to convert it back to string. If you want to control the output format, you need to specify it explicitly:
// Convert from string in "dd-MMM-yyyy" format to DateTime.
DateTime dt = DateTime.ParseExact("20-Oct-2012", "dd-MMM-yyyy", null);
// Convert from DateTime to string in "yyyy/MM/dd" format.
string str = dt.ToString("yyyy/MM/dd");
Also note that the mm format specifier represents minutes; months are represented by MM.
Edit: 'Converted date contain value "10/20/2012 12:00:00 AM".' Be careful what you mean by that. The constructed DateTime value contains an abstract representation of the parsed date and time that is independent of any format.
However, in order to display it, you need to convert it back into some string representation. When you view the variable in the debugger (as you're presumably doing), Visual Studio automatically calls the parameterless ToString() method on the DateTime, which renders the date and time under the current culture (which, in your case, assumes the US culture).
To alter this behaviour such that it renders the date and time under a custom format, you need to explicitly call the ToString(string) overload (or one of the other overloads), as I've shown in the example above.
You could try this instead :
Convert.ToDateTime("20-Oct-2012").ToString("yyyy/MM/dd")
Hope this will help !!
I am using the following function to determine whether input string is valid date or not.
public static bool IsDate(string date)
{
DateTime Temp;
if (DateTime.TryParse(date, out Temp))
return true;
else
return false;
}
Problem is when I give input "1997-09" then it returns true. I want it to check complete date like "1997-08-12"
And no there is no fix date format. Input could also be "19-Feb-2012"
And no there is no fix date format. Input could also be "19-Feb-2012"
There must be, otherwise it's nonesense. If you haven't defined how your system must behave you'd better stop coding and take a moment to define it.
You could use the TryParseExact method which allows you to specify one or more formats you would like to handle.
one easy condition you can add:
public static bool IsDate(string date)
{
DateTime Temp;
return(DateTime.TryParse(date, out Temp)&&date.Length>=10)
}
You should establish list of a correct date formats and then check with DateTime.TryParseExact, something like this:
string format = "yyyy-MM-dd";
DateTime dateTime;
if (DateTime.TryParseExact(dateString, format, CultureInfo.InvariantCulture,
DateTimeStyles.None, out dateTime))
Use DateTime.TryParse, you can specify the format then, more here. http://msdn.microsoft.com/en-us/library/9h21f14e.aspx
To resolve this you should define a datetime-format in your applicaiton.
On any webpage you go, if you see a compilation form, you probabbly will will see some date field too, and near it something like:
DD-MM-YYYY, or MM/DD/YY, or somethign else .
Define for your application format, make it esplicit for the user and check on correctness according to your format.
Just an hypothetic example:
say user inserted a date and you store it into the string like DD-MM-YYYY, one of possible choice could be simply say :
if(dateTimeUserString.Split('-').Length < 3)
//not valid string !
I repeat, this is just an example you should choose more appropriate way for your application.
DateTime.TryParse does have an overload that takes an IFormatProvider to allow specification of custom formats. You may need to define multiple IFormatPrividers to check the various strings you may expect as valid.
Also, rather than the if/else, you could also shorten your code a bit by
return DateTime.TryParse(date, out Temp);
You can return result of parsing directly:
public static bool IsDate(string value)
{
DateTime date;
return DateTime.TryParse(value, out date);
}
And it works with formats you have provided (at least when current culture "en-US").
Your code will run just fine and check the given date string if it can be a valid date using all of the current culture's date formats including this 19-Feb-2012 or 1997-09 of yours or even 19 february.
This makes you flexible in date input.
But if flexibility is not what your are looking for then try to parse for one or more specific formats using TryParseExact.
string strdate="15/06/2010";
DateTime dt =
DateTime.Parse(strdate,
System.Threading.Thread.CurrentThread.CurrentCulture.DateTimeFormat);
i cannot able to get the datetime value as dd/mm/yyyy.
it is giving exception 'string is not recognized as a valid datetime'
oly if it is in 06/15/2010 it is working. how to get the same format in dt.
Well, presumably your thread's current culture expects MM/dd/yyyy. If you want to use dd/MM/yyyy then you should specify that explicitly. Personally I prefer ParseExact instead of Parse, as that gives more control. I would use something like:
DateTime dt = DateTime.ParseExact(strdate, "dd/MM/yyyy",
CultureInfo.InvariantCulture);
Note that if this is user input, you may want to use TryParseExact instead.
You're currently using the current culture, which seems to be set up for US style date formats. Try this instead:
DateTime.Parse(strdate, System.Globalization.CultureInfo.CreateSpecificCulture("en-GB"));
This tells the function to use UK date style format which works. You might want to change the en-GB to whatever culture your dates will be in. If you have many calls where the culture is important it might also be worth to set it for the whole thread rather than call by call.
I have problem with the DateTime data type. Through a textbox I want to add person dateofbirth. As there is no date datatype in C# i am forced to use the DateTime datatype, but while converting TxtDateofBirth to DateTime i am getting an error, "String was not recognized as a valid DateTime." Here is my conversion the code. I kept this code in add event.
DateTime dateofbirth = Convert.ToDateTime(TxtDateOfBirth.Text);
What should I do?
Thanks,
Masum
Use DateTime.ParseExact with a format string which only specifies the date part.
Alternatively, as this is user input, use DateTime.TryParseExact so you don't need to catch an exception if the user has entered a bad date:
using System;
class Test
{
static void Main()
{
TestParsing("24/10/2009");
TestParsing("flibble");
}
static void TestParsing(string text)
{
DateTime dt;
if (DateTime.TryParseExact(text, "d", null, 0, out dt))
{
Console.WriteLine("Parsed to {0}", dt);
}
else
{
Console.WriteLine("Bad date");
}
}
}
Note that the format string "d" means "short date format" (see the "standard date and time form at strings" and "custom date and time format strings" pages in MSDN). "null" means "use the current culture" - so the above works for me in the UK, but you'd need to make the string "10/24/2009" in the US. You could specify a particular culture if you don't want to use the thread's current default. 0 means the default date and time style. Look at the MSDN page for more information.
Alternatively , use a mask so that users can only enter valid dates. (See the c# section under examples on the link given)
There is hardly anything one could add to Jon's answers, but in this case I'd like to make a point:
Try to understand that your problem is not because of the DateTime datatype but because your date string does not match the expected format (based on regional settings/thread culture) that the DateTime constructor.
You say that you are "forced" to use the DateTime datatype. You should keep in mind that Dates should always be treated as Dates. I've seen too many developers fall into the trap of using dates as strings (and performing split/search operations) rather than using DateTime because they feel that the latter is too complicated.