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
?
--
Jonathan Bailey. 7 2722
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
<jb> wrote in message news:41***********************@news.easynet.co.uk. ..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 ?
-- Jonathan Bailey.
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.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uA*************@tk2msftngp13.phx.gbl... 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
<jb> wrote in message news:41***********************@news.easynet.co.uk. ..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 ?
-- Jonathan Bailey.
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
Try this one:
testdates("00:0z")
It validates OK for me, but it shouldnt.
--
Jonathan Bailey.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oa*************@tk2msftngp13.phx.gbl... 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
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
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OI**************@TK2MSFTNGP10.phx.gbl... 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.
--
Jonathan Bailey.
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
<jb> wrote in message news:41**********************@news.easynet.co.uk.. . 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.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:uA*************@tk2msftngp13.phx.gbl... 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
<jb> wrote in message news:41***********************@news.easynet.co.uk. .. >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 > ? > > -- > Jonathan Bailey. > >
This discussion thread is closed Replies have been disabled for this discussion. Similar topics
10 posts
views
Thread by Douglas Buchanan |
last post: by
|
reply
views
Thread by Child |
last post: by
|
5 posts
views
Thread by darrel |
last post: by
|
2 posts
views
Thread by Ryanfai |
last post: by
|
6 posts
views
Thread by John A Grandy |
last post: by
|
11 posts
views
Thread by simon |
last post: by
|
3 posts
views
Thread by tshad |
last post: by
|
4 posts
views
Thread by Phillip Vong |
last post: by
|
5 posts
views
Thread by c_shah |
last post: by
|
2 posts
views
Thread by Tony K |
last post: by
| | | | | | | | | | | |