Type Conversion with Date formatted as YYYYMMDD

[Guest]

I have a string variable containing a date formatted as YYYYMMDD
For example - Dim x as string = "20070314"

If I try to perform a type conversion as follows I get an error:
Dim y as Date = CDATE(x)

How can I perform a type conversion for the date format YYYYMMDD?

Thanks.

 

[Mike Hofer]

I have a string variable containing a date formatted as YYYYMMDD
For example - Dim x as string = "20070314"

If I try to perform a type conversion as follows I get an error:
Dim y as Date = CDATE(x)

How can I perform a type conversion for the date format YYYYMMDD?

Thanks.

Private Function ConvertDate(ByVal value As String) As Date

' Converts a date in YYYYMMDD format to MM/DD/YYYY format.

If Not value.Length = 8 Then
Throw New ArgumentException("Invalid length")
End If

If Not IsNumeric(value) Then
Throw New ArgumentException("Not a valid 8-digit number.")
End If

Dim theYear As String = value.SubString(0, 4)
Dim theMonth As String = value.SubString(4, 2)
Dim theDay As String = value.SubString(6, 2)
Dim result As String = theMonth & "/" & theDay & "/" & theYear

If Not IsDate(result) Then
Throw New ArgumentException("value cannot be converted to a
valid date.")
End If

Return CDate(result)

End Function

Basically, parse it into it's constituent parts, then splice it back
together into the format you want. I'm sure there's a regular
expression you could use to do it, but I'm all for clear code that
maintenance programmers can read. Plus, I get to add lots of error
checking that validates the argument.

Hope this helps.

Mike

 

[Guest]

Absolutely Perfect! Thank you so very much for your assistance, Mike.

Mike

 

[Branco Medeiros]

I have a string variable containing a date formatted as YYYYMMDD
For example - Dim x as string = "20070314"

If I try to perform a type conversion as follows I get an error:
Dim y as Date = CDATE(x)

<snip>

I guess you'll be glad to know that the Date class has a Shared method
to do just that:

Dim D As Date = Date.ParseExact(X, "yyyyMMdd", Nothing)

HTH.

Regards,

Branco.

 

[Guest]

Branco, Perfect! Thank you!

<snip>

I guess you'll be glad to know that the Date class has a Shared method
to do just that:

Dim D As Date = Date.ParseExact(X, "yyyyMMdd", Nothing)

HTH.

Regards,

Branco.

 

[Cor Ligthert [MVP]]

Mike,

Why not use the constructor.

dim myDateString as string = CStr(New DateTime(2000, 1, 1).Date)

Cor

 

[Mike Hofer]

<snip>

I guess you'll be glad to know that the Date class has a Shared method
to do just that:

Dim D As Date = Date.ParseExact(X, "yyyyMMdd", Nothing)

HTH.

Regards,

Branco.

It never ceases to amaze me the kinds of stuff that I overlook in the
Framework. I use the DateTime class all the time. I don't know how
many times I've manually coded that solution, and didn't need to. I
should have figured there'd be a Framework method for handling it. I
just didn't look in the right place for it.

Thanks for pointing that out, Bronco.

 

[Mike Hofer]

Mike,

Why not use the constructor.

dim myDateString as string = CStr(New DateTime(2000, 1, 1).Date)

Cor

"Mike" <[email protected]> schreef in bericht






- Show quoted text -

He can't use the constructor for it, because the numbers are glommed
together in an 8-character string, and he has to parse them out.
Hence, Branco's suggestion of using the ParseExact method, which seems
eminently suited to the task.

 

[Branco Medeiros]

Mike Hofer wrote:

It never ceases to amaze me the kinds of stuff that I overlook in the
Framework. I use the DateTime class all the time. I don't know how
many times I've manually coded that solution, and didn't need to. I
should have figured there'd be a Framework method for handling it. I
just didn't look in the right place for it.

Tell me about it... This happens to me all the time. While it's great
to find a clever solution to a given problem by mining a ready-made
piece of code from the framework, some times it's just as frustrating
to dive into the framework and come out empty handed... just to
discover later that you were *this close* to the solution, but failed
to see it (or click in the correct MSDN help topic, actually).

I saw this happen just a few days ago, in another thread, while
looking up ways to discover schema information from the .Net data
providers (something that really interests me). The class that
actually provided the information was right there and I missed it
(despite some sort of intuition that kept telling me "look in the
datareader... look in the datareader..."). Fortunately Robin (a nod to
you, king) came out with the appropriate solution... ;-)

Thanks for pointing that out, Bronco.

Ops! "Bronco" (with an "o" in the 3rd letter) in portuguese means
"dumb". Thanks for pointing *that* out... =))))

Regards,

Branco.

 

[Mike Hofer]

Mike Hofer wrote:



Tell me about it... This happens to me all the time. While it's great
to find a clever solution to a given problem by mining a ready-made
piece of code from the framework, some times it's just as frustrating
to dive into the framework and come out empty handed... just to
discover later that you were *this close* to the solution, but failed
to see it (or click in the correct MSDN help topic, actually).

I saw this happen just a few days ago, in another thread, while
looking up ways to discover schema information from the .Net data
providers (something that really interests me). The class that
actually provided the information was right there and I missed it
(despite some sort of intuition that kept telling me "look in the
datareader... look in the datareader..."). Fortunately Robin (a nod to
you, king) came out with the appropriate solution... ;-)


Ops! "Bronco" (with an "o" in the 3rd letter) in portuguese means
"dumb". Thanks for pointing *that* out... =))))

Regards,

Branco.

DOH!

<slams head on desk>

Can I step in a big heapin' pile o' doggy doo or what?! :-D

 

[RobinS]

Mike Hofer wrote:


Tell me about it... This happens to me all the time. While it's great
to find a clever solution to a given problem by mining a ready-made
piece of code from the framework, some times it's just as frustrating
to dive into the framework and come out empty handed... just to
discover later that you were *this close* to the solution, but failed
to see it (or click in the correct MSDN help topic, actually).

I saw this happen just a few days ago, in another thread, while
looking up ways to discover schema information from the .Net data
providers (something that really interests me). The class that
actually provided the information was right there and I missed it
(despite some sort of intuition that kept telling me "look in the
datareader... look in the datareader..."). Fortunately Robin (a nod to
you, king) came out with the appropriate solution... ;-)


Ops! "Bronco" (with an "o" in the 3rd letter) in portuguese means
"dumb". Thanks for pointing *that* out... =))))

Regards,

Branco.

Thanks, Branco. I'm glad I posted something that was helpful to you!

Robin S.