DateDiff just got complicated

  • Thread starter Thread starter Danny J. Lesandrini
  • Start date Start date
D

Danny J. Lesandrini

Maybe I'm missing something, but a search of Google suggested that I need to do the
following to perform DateDiff in VB .Net with native CLR calls. Watch for word wrap ...
there's plenty of room for it with the verbosity of this code ...

Dim d1 As Date = DateTime.Parse(txtEndDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim d2 As Date = DateTime.Parse(txtStartDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim ts As TimeSpan = d1.Subtract(d2)
Dim DateRangeWarning As Integer= ts.Days

How is that code "better" than this ...
Dim DateRangeWarning As Integer= DateDiff(DateInterval.Day, CDate(txtStartDate.Text), CDate(txtEndDate.Text))

The DateDiff call works in VB .Net but of course it's legacy code. Does this mean that
any time I want to use DateDiff, I need to instantiate 3 seperate objects? Thank goodness
for automatic garbage collection.

Danny Lesandrini
(e-mail address removed)
 
Well, you could do something like:

Dim DateRangeWarning As Integer = DateTime.Parse(txtEndDate.Text).Substract(DateTime.Parse(txtStartDate.Text)).Days

Which isn't that long. The second snippet you showed doesn't do anything with date time format info's or anything like that, so your first example was making things way more complicated then in the second one. Also, to be fair, your second example should have looked like this:

Dim d1 As Date = CDate(txtStartDate.Text)
Dim d2 As Date = CDate(txtEndDate.Text)
Dim DateRangeWarning As Integer = DateDiff(DateInterval.Day,d2,d1)

In any case, the first code snippet is also one line, not much longer then what you have that uses DateDiff.

By the way, the other benefit is if you ever convert this code to another language, it will be much easier, as opposed to if you are using datediff.
Maybe I'm missing something, but a search of Google suggested that I need to do the
following to perform DateDiff in VB .Net with native CLR calls. Watch for word wrap ...
there's plenty of room for it with the verbosity of this code ...

Dim d1 As Date = DateTime.Parse(txtEndDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim d2 As Date = DateTime.Parse(txtStartDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim ts As TimeSpan = d1.Subtract(d2)
Dim DateRangeWarning As Integer= ts.Days

How is that code "better" than this ...
Dim DateRangeWarning As Integer= DateDiff(DateInterval.Day, CDate(txtStartDate.Text), CDate(txtEndDate.Text))

The DateDiff call works in VB .Net but of course it's legacy code. Does this mean that
any time I want to use DateDiff, I need to instantiate 3 seperate objects? Thank goodness
for automatic garbage collection.

Danny Lesandrini
(e-mail address removed)
 
Hi Danny,

Maybe I understand your question wrong, but to get a timespan, this is
enough in my opinion.


Dim span As TimeSpan =
CDate(txtEndDate.Text).Subtract(CDate(txtStartDate.Text))

Asuming the date in the textboxes are right.

I hope this helps?

Cor
 
Thanks Marina ... that's exactly what I was looking for ... but it doesn't work ... doesn't parse.

When I pasted that code in my project, I got the little squiggly blue line under this part ...
DateTime.Parse(txtEndDate.Text).Substract

.... and a tool-tip message that Subtract wasn't a member of 'Date'. That's what makes this
language so frustrating to me. I just can't wrap my mind around the correct syntax.

Danny




Dim DateRangeWarning As Integer = DateTime.Parse(txtEndDate.Text).Substract(DateTime.Parse(txtStartDate.Text)).Days

Which isn't that long. The second snippet you showed doesn't do anything with date time format info's or anything like that, so your first example was making things way more complicated then in the second one. Also, to be fair, your second example should have looked like this:

Dim d1 As Date = CDate(txtStartDate.Text)
Dim d2 As Date = CDate(txtEndDate.Text)
Dim DateRangeWarning As Integer = DateDiff(DateInterval.Day,d2,d1)

In any case, the first code snippet is also one line, not much longer then what you have that uses DateDiff.

By the way, the other benefit is if you ever convert this code to another language, it will be much easier, as opposed to if you are using datediff.
Maybe I'm missing something, but a search of Google suggested that I need to do the
following to perform DateDiff in VB .Net with native CLR calls. Watch for word wrap ...
there's plenty of room for it with the verbosity of this code ...

Dim d1 As Date = DateTime.Parse(txtEndDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim d2 As Date = DateTime.Parse(txtStartDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim ts As TimeSpan = d1.Subtract(d2)
Dim DateRangeWarning As Integer= ts.Days

How is that code "better" than this ...
Dim DateRangeWarning As Integer= DateDiff(DateInterval.Day, CDate(txtStartDate.Text), CDate(txtEndDate.Text))

The DateDiff call works in VB .Net but of course it's legacy code. Does this mean that
any time I want to use DateDiff, I need to instantiate 3 seperate objects? Thank goodness
for automatic garbage collection.

Danny Lesandrini
(e-mail address removed)
 
I mispelled 'Subtract', and wrote 'Substract' instead.
Thanks Marina ... that's exactly what I was looking for ... but it doesn't work ... doesn't parse.

When I pasted that code in my project, I got the little squiggly blue line under this part ...
DateTime.Parse(txtEndDate.Text).Substract

... and a tool-tip message that Subtract wasn't a member of 'Date'. That's what makes this
language so frustrating to me. I just can't wrap my mind around the correct syntax.

Danny




Dim DateRangeWarning As Integer = DateTime.Parse(txtEndDate.Text).Substract(DateTime.Parse(txtStartDate.Text)).Days

Which isn't that long. The second snippet you showed doesn't do anything with date time format info's or anything like that, so your first example was making things way more complicated then in the second one. Also, to be fair, your second example should have looked like this:

Dim d1 As Date = CDate(txtStartDate.Text)
Dim d2 As Date = CDate(txtEndDate.Text)
Dim DateRangeWarning As Integer = DateDiff(DateInterval.Day,d2,d1)

In any case, the first code snippet is also one line, not much longer then what you have that uses DateDiff.

By the way, the other benefit is if you ever convert this code to another language, it will be much easier, as opposed to if you are using datediff.
Maybe I'm missing something, but a search of Google suggested that I need to do the
following to perform DateDiff in VB .Net with native CLR calls. Watch for word wrap ...
there's plenty of room for it with the verbosity of this code ...

Dim d1 As Date = DateTime.Parse(txtEndDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim d2 As Date = DateTime.Parse(txtStartDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim ts As TimeSpan = d1.Subtract(d2)
Dim DateRangeWarning As Integer= ts.Days

How is that code "better" than this ...
Dim DateRangeWarning As Integer= DateDiff(DateInterval.Day, CDate(txtStartDate.Text), CDate(txtEndDate.Text))

The DateDiff call works in VB .Net but of course it's legacy code. Does this mean that
any time I want to use DateDiff, I need to instantiate 3 seperate objects? Thank goodness
for automatic garbage collection.

Danny Lesandrini
(e-mail address removed)
 
I ran a code analysis tool on my .Net project. (FMS .Net Analyzer
www.fmsinc.com )
It suggests that things like DateDiff, DateAdd, CDate and the like are "old
VB" code and
should be upsized to true, CLR approved, VB .Net code. That's what I was
trying to do.

All I really want is a DateDiff on string values in two text boxes. I don't
think it should
require 4 lines of code.

All the same, thanks for your input.

Danny
 
Also, the language isn't any different then before, really. It was always possible to nest method calls, and to be able to call a method on an object that was the result of calling another method.
Thanks Marina ... that's exactly what I was looking for ... but it doesn't work ... doesn't parse.

When I pasted that code in my project, I got the little squiggly blue line under this part ...
DateTime.Parse(txtEndDate.Text).Substract

... and a tool-tip message that Subtract wasn't a member of 'Date'. That's what makes this
language so frustrating to me. I just can't wrap my mind around the correct syntax.

Danny




Dim DateRangeWarning As Integer = DateTime.Parse(txtEndDate.Text).Substract(DateTime.Parse(txtStartDate.Text)).Days

Which isn't that long. The second snippet you showed doesn't do anything with date time format info's or anything like that, so your first example was making things way more complicated then in the second one. Also, to be fair, your second example should have looked like this:

Dim d1 As Date = CDate(txtStartDate.Text)
Dim d2 As Date = CDate(txtEndDate.Text)
Dim DateRangeWarning As Integer = DateDiff(DateInterval.Day,d2,d1)

In any case, the first code snippet is also one line, not much longer then what you have that uses DateDiff.

By the way, the other benefit is if you ever convert this code to another language, it will be much easier, as opposed to if you are using datediff.
Maybe I'm missing something, but a search of Google suggested that I need to do the
following to perform DateDiff in VB .Net with native CLR calls. Watch for word wrap ...
there's plenty of room for it with the verbosity of this code ...

Dim d1 As Date = DateTime.Parse(txtEndDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim d2 As Date = DateTime.Parse(txtStartDate.Text.ToString, System.Globalization.DateTimeFormatInfo.CurrentInfo)
Dim ts As TimeSpan = d1.Subtract(d2)
Dim DateRangeWarning As Integer= ts.Days

How is that code "better" than this ...
Dim DateRangeWarning As Integer= DateDiff(DateInterval.Day, CDate(txtStartDate.Text), CDate(txtEndDate.Text))

The DateDiff call works in VB .Net but of course it's legacy code. Does this mean that
any time I want to use DateDiff, I need to instantiate 3 seperate objects? Thank goodness
for automatic garbage collection.

Danny Lesandrini
(e-mail address removed)
 
Well, that's a different kettle of fish entirely. That code worked

Dim LargeDateRange As Integer = DateTime.Parse(txtEndDate.Text).Subtract(DateTime.Parse(txtStartDate.Text)).Days

Thanks for your help. My frustration is alleviated and my faith in .Net restored :-)

Danny
I mispelled 'Subtract', and wrote 'Substract' instead.
Thanks Marina ... that's exactly what I was looking for ... but it doesn't work ... doesn't parse.

When I pasted that code in my project, I got the little squiggly blue line under this part ...
DateTime.Parse(txtEndDate.Text).Substract

... and a tool-tip message that Subtract wasn't a member of 'Date'. That's what makes this
language so frustrating to me. I just can't wrap my mind around the correct syntax.

Danny
 
Hi Danny,

Cxxx commands are the right Cast commands in VB.net for casting values. (And
date is a value type in VB.net).

Cor
 
If you put your cursor on CDate() in Visual Studio code module and press F1,
you
get a help page titled "Visual Basic Language Reference". These calls are
supported ...
for now, but the way I understand it, they are NOT .Net.
 
Well, CDate, CStr, etc, are all shortcuts to CType, but they are already
specific to converting to a particular type. Since VB.NET doesn't support
casting operators, you have to use these Cxxx calls instead. So yes, in
general, there is no CDate operator in .NET that any language can use. On
the other hand, if you are using VB.NET, and you need to cast something, to
let's say an IEnumerator, you have to use CType, as there is no other syntax
that would resemble C#'s.
 
[...]

Your post is unreadable in some newsreaders. Consider posting in
text/plain format in future. Thank you.
 
Back
Top