Visual Basic Frequently Asked Questions : Language

How do I determine the difference between two dates?

vbfaq — Sun, 30 May 2004 08:05:00 GMT

Posted by: Duncan Mackenzie, MSDN
This post applies to Visual Basic .NET 2002/2003

This common question is often phrased as "How do I find the number of hours between two dates?", substituting minutes, seconds, days, or whatever interval you are looking for in the place of 'hours'. Well, in Visual Basic .NET there are two main ways to achieve this result; the DateDiff function or through the TimeSpan structure.

Both of these methods are equally valid, where they overlap in functionality, but each of them has a couple of unique features. Despite their similar functions, the core difference between the two is that DateDiff is a function, so you need to call it every time you need to retrieve a value, whereas TimeSpan is a structure that is created once and then you just work with its various members as needed.

Using DateDiff, you call it with different date interval parameters to retrieve the appropriate value:

        Dim D1, D2 As Date
        D1 = Date.Now
        D2 = #11/9/2004#
        'DateDiff
        Console.WriteLine("DateDiff")
        Console.WriteLine()
        Console.WriteLine("{0} Days", _
            DateDiff(DateInterval.Day, D1, D2))
        Console.WriteLine("{0} Hours", _
            DateDiff(DateInterval.Hour, D1, D2))
        Console.WriteLine("{0} Minutes", _
            DateDiff(DateInterval.Minute, D1, D2))
        Console.WriteLine("{0} Seconds", _
            DateDiff(DateInterval.Second, D1, D2))
        Console.WriteLine()

Alternatively, a TimeSpan structure can be retrieved as the result of subtracting one date from another, and then querying the various members of that structure.

        'TimeSpan
        Console.WriteLine("TimeSpan")
        Console.WriteLine()
        Dim difference As TimeSpan = D2.Subtract(D1)
        Console.WriteLine("{0} Days", difference.TotalDays)
        Console.WriteLine("{0} Hours", difference.TotalHours)
        Console.WriteLine("{0} Minutes", difference.TotalMinutes)
        Console.WriteLine("{0} Seconds", difference.TotalSeconds)
        Console.WriteLine()

The output of the two different methods is nearly identical, except that the TimeSpan properties are returning Doubles, while DateDiff always returns Longs (Int64).

DateDiff

175 Days
4222 Hours
253345 Minutes
15200730 Seconds

TimeSpan

175.934383644387 Days
4222.42520746528 Hours
253345.512447917 Minutes
15200730.746875 Seconds

The fractional values returned from the TimeSpan properties are more meaningful that they might seem at first glance; each of these properties is returning the complete difference between the two dates, whereas the whole numbers returned from DateDiff only provide a value to within one interval (day, hour, etc…). Using only one of these properties from TimeSpan, it would be possible to figure out any other time interval (with varying degrees of precision, of course), although that calculation would seldom be required in practice.

The TimeSpan structure provides additional members (.Hours, .Days, etc...) that return values closer to what you see from DateDiff, so you can use those if it is more suitable for your situation. While TimeSpan can appear to have more features and to be more efficient, DateDiff has two benefits that may cause you to continue to use it in your Visual Basic .NET applications:

It provides several date intervals that are not covered by TimeSpan, including Weeks and Quarters, and
It is compatible with the VB6 function of the same name, allowing you to more easily reuse existing code.

Read the corresponding documentation for more information, but I hope that this has been helpful...

Workaround: Arrays with non-zero lower bounds

vbfaq — Tue, 20 Apr 2004 10:59:00 GMT

Posted by: Phil Weber, VB MVP
This post applies to Visual Basic .NET 2002/2003/2005

OK, now that Paul Vick has explained why VB.NET doesn't support arrays with non-zero lower bounds, let's see how we can do them anyway. ;-)

Say you want to store a collection of annual values in an array of integers. It's reasonable that the array index would correspond to the year in question; that is, TotalSales(1981) would contain the sales total for the year 1981.

In pre-.NET versions of VB, we could simply do this:

    Dim TotalSales(1981 To 2000) As Integer

Problem solved. But as Paul has explained, VB.NET no longer lets us do that. We can, however, do this:

    Dim TotalSales As New VBArray(1981, 2000)
    TotalSales(1981) = 345
    TotalSales(2000) = 995
    Console.WriteLine(TotalSales(1981))
    Console.WriteLine(TotalSales(2000))

I can live with that, how about you?

This class (based on this post by Eric Gunnerson) is what makes it all possible:

Public Class VBArray
     Private _lbound As Integer
     Private _int() As Integer 

     Public Sub New(ByVal LBound As Integer, ByVal UBound As Integer)
         Me.ReDim(LBound, UBound)
     End Sub 

     Public Sub [ReDim](ByVal LBound As Integer, ByVal UBound As Integer)
         _lbound = LBound
         ReDim _int(UBound - LBound + 1)
     End Sub 

     Default Public Property Item(ByVal Index As Integer) As Integer
         Get
             Return _int(Index - _lbound)
         End Get
         Set(ByVal Value As Integer)
             _int(Index - _lbound) = Value
         End Set
     End Property 

     Public Function ToArray() As Integer()
         Return _int
     End Function
 End Class

I've included a ToArray method which returns the underlying array, in case you need to pass it to another method, or manipulate it in other array-type ways.

Note that this class is hard-coded to handle Integers; in VB.NET 2002/2003, you must create a separate class for each array type you wish to simulate. Generics in Visual Basic .NET 2005 will make this sort of thing much cleaner.

Why doesn't VB support non-zero lower bounds for arrays?

vbfaq — Tue, 20 Apr 2004 10:01:00 GMT

Posted by: Duncan Mackenzie, MSDN
This post applies to Visual Basic .NET 2002/2003/2005

Another answer from Paul Vick, Technical Lead on VB.NET, explaining the changes in array bounds from Visual Basic 6.0:

Why doesn't VB support non-zero lower bounds for arrays?
... We allowed programmers to declare arrays that had bounds from 1 to 20, or from 1001 to 2000 or whatever. Even more puzzling, Eric points out that the CLR does support such arrays. So if there's no historical problem and there's no technical problem, why doesn't VB have non-zero lower bound arrays? ...

Why did Visual Basic .NET introduce AndAlso and OrElse?

vbfaq — Tue, 20 Apr 2004 07:47:00 GMT

Posted by: Duncan Mackenzie, MSDN
This post applies to Visual Basic .NET 2002/2003/2005

Paul Vick, Technical Lead on VB.NET, and the author of the Visual Basic .NET Language Specification, discusses the new short-circuiting boolean operators added in Visual Basic .NET 2002.

Why did we introduce AndAlso and OrElse?
... Prior to VB.NET, the VB language only had the And and Or operators. They were essentially bitwise operators, which means that they took their two operands and performed an AND or OR operation on each bit position to produce the resulting bit...

Operator Overloading?

vbfaq — Tue, 20 Apr 2004 06:54:00 GMT

Posted by: Phil Weber, VB MVP
This post applies to Visual Basic .NET 2005 (“Whidbey”)

Gokhan Altinoren asks:

What was the design decision behind the fact that VB.NET does not support operator overloading? Will this feature be in the VB.NET specification in the future?

Sadly, the VB team failed to consult me while they were designing the language, so I can't comment on why they decided not to support operator overloading in VB.NET (although if I had to guess, I'd wager that it was on the list of “nice-to-have” features that had to be postponed in order to ship VB.NET during the Bush administration).

The good news is that it is slated for the next release of VB (Visual Basic .NET 2005, code-named Whidbey). For more information, see:

http://blogs.gotdotnet.com/cambecc/permalink.aspx/5de5a161-9150-4237-a751-127195cceeab
http://weblogs.asp.net/cfranklin/archive/2003/11/14/37580.aspx