DateTime.Parse fails at VB2005
-
I have an application that has worked happily for many years under VB2003. Today I upgraded it to VB2005 with no upgrade issues or changes. The following line now fails dim datestr as string = "7thNovember1993" dim datedate as date datedate = System.DateTime.Parse(datestr) VB2005 throws The string was not recognized as a valid DateTime. There is a unknown word starting at index 1. TOPSie
-
I have an application that has worked happily for many years under VB2003. Today I upgraded it to VB2005 with no upgrade issues or changes. The following line now fails dim datestr as string = "7thNovember1993" dim datedate as date datedate = System.DateTime.Parse(datestr) VB2005 throws The string was not recognized as a valid DateTime. There is a unknown word starting at index 1. TOPSie
You now have to use DateTime.ParseExact[^] and supply the format string that describes the format in which it should expect the date. Read the link I supplied, near the bottom, for an in-depth description of how ParseExact works and creating custom format strings to tell the parser what to expect.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
You now have to use DateTime.ParseExact[^] and supply the format string that describes the format in which it should expect the date. Read the link I supplied, near the bottom, for an in-depth description of how ParseExact works and creating custom format strings to tell the parser what to expect.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Thanks for this - what a giant leap - backwards. If I understand this then 7 November 1993 has a format string of "d MMMM YYYY" But all my dates (and the data has LOTS of them) are in the format 7th November 1993. I can find nothing in your link that shows me a format to cope with "th" (or "st" or "rd"). I presume I am going to have to strip these out of the input string myself - being careful with AuguST etc. As I said a great leap forward - one line of code turns in to 10 or more!!! STOP PRESS The original error was in DateTime.Parse coping with "7th November 1993" Following your link I tried ParseExact with a format string of "d MMMM YYYY" after stripping the "th" out. But ParseExact returned an error. However going back to just Parse with no "th" in the date string now seems to work. Thanks again TOPSie -- modified at 13:25 Friday 29th June, 2007 TOPSie
-
Thanks for this - what a giant leap - backwards. If I understand this then 7 November 1993 has a format string of "d MMMM YYYY" But all my dates (and the data has LOTS of them) are in the format 7th November 1993. I can find nothing in your link that shows me a format to cope with "th" (or "st" or "rd"). I presume I am going to have to strip these out of the input string myself - being careful with AuguST etc. As I said a great leap forward - one line of code turns in to 10 or more!!! STOP PRESS The original error was in DateTime.Parse coping with "7th November 1993" Following your link I tried ParseExact with a format string of "d MMMM YYYY" after stripping the "th" out. But ParseExact returned an error. However going back to just Parse with no "th" in the date string now seems to work. Thanks again TOPSie -- modified at 13:25 Friday 29th June, 2007 TOPSie
TotalTops1972 wrote:
Thanks for this - what a giant leap - backwards.
Not really. This method is more flexible than what it used to be.
TotalTops1972 wrote:
But all my dates (and the data has LOTS of them) are in the format 7th November 1993.
This is a really bad format. Sure it's human readable, but it makes it a PITA to use in automated data processing. Forget searching the database between date ranges. This is a string of characters that looks like a date. It's not actually a date value.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
TotalTops1972 wrote:
Thanks for this - what a giant leap - backwards.
Not really. This method is more flexible than what it used to be.
TotalTops1972 wrote:
But all my dates (and the data has LOTS of them) are in the format 7th November 1993.
This is a really bad format. Sure it's human readable, but it makes it a PITA to use in automated data processing. Forget searching the database between date ranges. This is a string of characters that looks like a date. It's not actually a date value.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007I appreciate your reply, it is a human format. This is raw data which originates from written documents, once upon a time they were handed copied, then scanned, now I get it electronically, but it from a printed document intended to be read by real people! My program is reading this raw data and immediately converting it into a useful computer format so I can use it - but I have to take the original data in the format it is written. Thanks to your help I have now got this initial conversion code working in at least one path - just hit another, but now I know how to fix it then it is just a slog to spot all the conversion paths.. My step backwards remark is aimed at Microsoft - backwards compatibility is something they often don't rate too highly. Thanks again.... TOPSie
-
I appreciate your reply, it is a human format. This is raw data which originates from written documents, once upon a time they were handed copied, then scanned, now I get it electronically, but it from a printed document intended to be read by real people! My program is reading this raw data and immediately converting it into a useful computer format so I can use it - but I have to take the original data in the format it is written. Thanks to your help I have now got this initial conversion code working in at least one path - just hit another, but now I know how to fix it then it is just a slog to spot all the conversion paths.. My step backwards remark is aimed at Microsoft - backwards compatibility is something they often don't rate too highly. Thanks again.... TOPSie
I'd look into using a Regular Expression to get the date string at least partially normalized so ParseExact has a better shot at it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Thanks for this - what a giant leap - backwards. If I understand this then 7 November 1993 has a format string of "d MMMM YYYY" But all my dates (and the data has LOTS of them) are in the format 7th November 1993. I can find nothing in your link that shows me a format to cope with "th" (or "st" or "rd"). I presume I am going to have to strip these out of the input string myself - being careful with AuguST etc. As I said a great leap forward - one line of code turns in to 10 or more!!! STOP PRESS The original error was in DateTime.Parse coping with "7th November 1993" Following your link I tried ParseExact with a format string of "d MMMM YYYY" after stripping the "th" out. But ParseExact returned an error. However going back to just Parse with no "th" in the date string now seems to work. Thanks again TOPSie -- modified at 13:25 Friday 29th June, 2007 TOPSie
I found a way to cope with 'th', 'st', 'nd' and 'rd'. It's not that pretty but if you wrap it up into a function you've got a workable solution. It would be nice if you could just ignore characters, then you could use something like "d##MMMMyyyy" where # would be a character that's ignored. However, I couldn't find anything in the documentation that would lead me to believe that's possible. Anyway here you go.
' Valid date formats Dim validFormats As String() = {"d'st'MMMMyyyy", "d'nd'MMMMyyyy", "d'rd'MMMMyyyy", "d'th'MMMMyyyy"} Dim myDate As Date = Date.ParseExact("1stDecember1993", validFormats, Globalization.CultureInfo.CurrentCulture, Globalization.DateTimeStyles.None)
Your original post showed no spaces for the date...it was 7thNovember1993. If that's not the case just add appropriate spaces into the formatting strings and it should work.