Ctype(Stinrg,Date) works with non-numerics

[Guest]

I am trying to validate a textfield to ensure it holds a time. I use a
try/catch block to see if I can convert to a time & if it works then I
blindly 'assume' it was OK.

This single line

Dim y As Date = CType("00:0z", Date)

gives me a time of 1:00 am, whereas
Dim z As Date = Date.Parse("00:0z")

gives me the same time but with today's date


Is this a bug or a feature of the framework ? Does anyone have a better idea
?

 

[Jay B. Harlow [MVP - Outlook]]

Jonathan,

Is this a bug or a feature of the framework ?

I don't consider it a bug nor a feature.

CType & CDate are VB.NET functions that have defined functionality.

DateTime.Parse is a BCL (Base class library) method that has defined
functionality.

Although a number of the VB.NET functions are implemented in terms of the
BCL, some have their own specific behaviors, normally I find the VB.NET
functions will try harder, in that they are more tolerant of invalid values
(indexes out of range & such).

Does anyone have a better idea?

I wouldn't mix & match DateTime.Parse & CDate in the same program if I
wanted consistent results.

Just like I don't mix String methods with VB.Strings methods, as the String
methods are 0 based indexing, while VB.Strings are 1 based indexing.

Both are examples of "Oddball Solution smell" which means "When a problem is
solved one way throughout a system and the same problem is solved another
way in the same system, one of the solutions is hte oddball or inconsistent
solution", Oddball here means using DateTime.Parse & CDate, not that one of
them returns a different result. The different result is just an extra
factor in the puzzle...

Oddball Solution Smell is defined in Joshua Kerievsky's book "Refactoring to
Patterns" from Addison Wesley.

Hope this helps
Jay

 

[Guest]

I found that timespan.parse seems to validate better. I have to eliminate
any response with a '.' as that would allow a number of days. Any other
suggestions to validate just hh:mm:ss ?

--
Jonathan Bailey.

Jonathan,

Is this a bug or a feature of the framework ?

I don't consider it a bug nor a feature.

CType & CDate are VB.NET functions that have defined functionality.

DateTime.Parse is a BCL (Base class library) method that has defined
functionality.

Although a number of the VB.NET functions are implemented in terms of the
BCL, some have their own specific behaviors, normally I find the VB.NET
functions will try harder, in that they are more tolerant of invalid values
(indexes out of range & such).

Does anyone have a better idea?

I wouldn't mix & match DateTime.Parse & CDate in the same program if I
wanted consistent results.

Just like I don't mix String methods with VB.Strings methods, as the String
methods are 0 based indexing, while VB.Strings are 1 based indexing.

Both are examples of "Oddball Solution smell" which means "When a problem is
solved one way throughout a system and the same problem is solved another
way in the same system, one of the solutions is hte oddball or inconsistent
solution", Oddball here means using DateTime.Parse & CDate, not that one of
them returns a different result. The different result is just an extra
factor in the puzzle...

Oddball Solution Smell is defined in Joshua Kerievsky's book "Refactoring to
Patterns" from Addison Wesley.

Hope this helps
Jay

 

[Cor Ligthert]

Jb,

This is the normal one, which I made in a complete sample for you to show
it.
(the important part for you is only "IsDate"

\\\
Public Module testDates
Public Sub Main()
testdates(Now.ToString)
testdates(New DateTime(2004, 1, 3).ToString)
testdates("blablalba")
End Sub
Private Sub testdates(ByVal value As String)
If IsDate(value) Then
MessageBox.Show(value & "=I am a correct date")
Else
MessageBox.Show(value & "=I am not a date")
End If
End Sub
End Module
///

I hope this helps?

Cor

 

[Guest]

Try this one:
testdates("00:0z")
It validates OK for me, but it shouldnt.

 

[Cor Ligthert]

JB,

Look at this page, (although there is written a Capital Z Zulu time). So
when this is as strict as written here, it is in my opinion a bug.

http://www.grc.nasa.gov/WWW/MAEL/ag/zulu.htm

However I do not know that, I only looked at this page and one other page
where is stated the same.

Cor

 

[Guest]

JB,

Look at this page, (although there is written a Capital Z Zulu time). So
when this is as strict as written here, it is in my opinion a bug.

http://www.grc.nasa.gov/WWW/MAEL/ag/zulu.htm

However I do not know that, I only looked at this page and one other page
where is stated the same.

Cor

Thanks - We have a system which includes what is known as the 'Disney
date' - this was for those years when a leap year occurred but so as to
allow the users to refer to 31th December as 365 the 29th Febuary was turned
into 366, so maybe a z in the time isnt quite so funny as I thought.

 

[Jay B. Harlow [MVP - Outlook]]

Jonathan,
I would primarily use TimeSpan.Parse when I needed to parse time spans (a
duration).

I would primarily use either DateTime.Parse or CDate then I needed to parse
dates, times (time of day), or dates w/times. However I would make every
effort to use only DateTime.Parse or CDate within a single solution.

Hope this helps
Jay

I found that timespan.parse seems to validate better. I have to eliminate
any response with a '.' as that would allow a number of days. Any other
suggestions to validate just hh:mm:ss ?