string to date

  • Thread starter Thread starter cj
  • Start date Start date
C

cj

This works:

If remoteFileInfo(arrayIndex).m_strFileDate < Now.AddDays(-25) Then ....

but should it???

remoteFileInfo(arrayIndex).m_strFileDate is a string for example:
"9/6/2007 7:00:00 AM"

Now.AddDays(-25) is a date for example:
#8/12/2007 10:52:56 AM#

Shouldn't I be converting remoteFileInfo(arrayIndex).m_strFileDate to a
date before compairing?
 
This works:
If remoteFileInfo(arrayIndex).m_strFileDate < Now.AddDays(-25) Then
....

but should it???
Click to expand...

I'm nopt in a position to test this right now but I would have to guess something
like.

You are not using "option Strict on"
VB.net may be converting your date to a strng for comparison purposes

This means that you are likely getting lucky for now.

I would suggest
 
Found it.

If cdate(remoteFileInfo(arrayIndex).m_strFileDate < Now.AddDays(-25)

is what I was looking for.

P.S. I like option strict off but it was bugging me that I couldn't
remember how to convert a string to a date. All I could think of was
stod() which is VFP.
 
cj said:
This works:

If remoteFileInfo(arrayIndex).m_strFileDate < Now.AddDays(-25) Then ....

but should it???
Click to expand...

No, it doesn't work. It might compile, but it doesn't work. The date
will be converted to a string, and comparing dates as strings doesn't
work unless you use the ISO 8601 format.
remoteFileInfo(arrayIndex).m_strFileDate is a string for example:
"9/6/2007 7:00:00 AM"

Now.AddDays(-25) is a date for example:
#8/12/2007 10:52:56 AM#

Shouldn't I be converting remoteFileInfo(arrayIndex).m_strFileDate to a
date before compairing?
Click to expand...

Yes. Use the Convert.ToDateTime method.
 
cj said:
Yes, it did work. Can't say why, but it did.
Click to expand...

I see. Yes, actually it does work in this case. For some reason it
converts the string to a date, not the date to a string.

Relying on that the compiler manages to correctly guess what you mean is
not a good practice, though. You should use "Option Script On" so that
you don't do conversions like this by mistake.

If you don't know why something works, you can't know if it's actually
working correctly for all possible cases, or if it's going to work in
the future. Just because something looks like it works doesn't
automatically mean that it's correct. I've seen code that has been used
for years, that suddenly failed just because it was wrong from the
beginning.
 
Göran Andersson said:
I see. Yes, actually it does work in this case. For some reason it
converts the string to a date, not the date to a string.

Relying on that the compiler manages to correctly guess what you mean is
not a good practice, though. You should use "Option Script On" so that
you don't do conversions like this by mistake.
Click to expand...

IYHO of course :)
 
cj said:
IYHO of course :)
Click to expand...

I'd *think* you'll find that *most* people (I wonder how much trouble I can
get in for using that phrase wthout actually asking most people ;P) would
agree with Goran.

Codeing VB.net without "Option Strict On" as a *default* stance can be much
like the difference between coding VBA and Coding VB6

If there is a possibility that the compiler could get it wrong, then you
shouldn't leave it up to the compiler. you should tell the compiler explicitly.
"Option Strict on" is a great way to get the compiler to tell you where the
uncertainty is.

That said there are places where the reverse is true,. It's just that there
are not many so IMHO (:)) the deafult should be "Option strict On"
 
I'd *think* you'll find that *most* people (I wonder how much trouble I can
get in for using that phrase wthout actually asking most people ;P) would
agree with Goran.
Click to expand...

Don't worry Rory - if you, Goran, and I all agree about Option Strict
On then it has to be right. After all we're know better than *most*
people (hehe just kidding - no flames please :-))

It's true though - I see no reason why any developer would leave this
off, unless they have to use late-binding (though I believe you could
just suppress the message). The annoyance of having to explicitly cast/
convert all your types is nothing compared to having to explain to a
client that that phantom crash they keep having is because of you
forgot to cast a string into a integer before multiplying. Besides, if
you ever plan on using a different language (say C#) you need to get
used to explicitly declaring everything, as C# is more picky than VB
with Option Strict On.

After all, the old saying is "Never put off until runtime what you can
fix at compile time."

Or something like that...

Thanks,

Seth Rowe
 
Back
Top