Date and Time Difference in Minutes

Question

Is there any way to Display the difference between 2 different times. I currently have 2 buttons.

Sub AddButtonClick(sender As Object, e As EventArgs)

    StartTime.Text = DateTime.Now.ToString()

End Sub

This generates the first timestamp

Sub EndBreakClick(sender As Object, e As EventArgs)

    EndTime.Text = DateTime.Now.ToString()

    DateDiff(DateInterval.Minute, Endtime, StartTime)
End Sub

This generates the second timestamp but the datediff line causes the app to crash as soon as I press the button.

varocarbas · Accepted Answer · 2015-08-18T15:14:07.537

10

You can rely on TimeSpan:

Dim elapsedTime As TimeSpan = DateTime.Parse(EndTime.Text).Subtract(DateTime.Parse(StartTime.Text))

It behaves as a normal time variable from which you can extract all the information you want. Example:

Dim elapsedMinutesText As String = elapsedTime.Minutes.ToString()

Bear in mind that the code above takes string variables as inputs (the text from your textboxes) because it performs the corresponding conversion: Convert.ToDateTime.

Regarding your code, it refers to EndTime and StartTime and these are not DateTime variables, but TextBoxes. You have to convert them (their text) into DateTime as I am doing above, that is:

DateDiff(DateInterval.Minute, DateTime.Parse(EndTime.Text), DateTime.Parse(StartTime.Text))

edited Aug 18 '15 at 15:14

answered Jul 20 '13 at 18:30

varocarbas

12,354
4
26
37

1

This will work, but it will throw an exception if one of the TextBox values doesn't hold a valid DateTime. You will probably want to catch that exception, or use DateTime.TryParse instead to avoid throwing the exception. – Douglas Barbin Jul 20 '13 at 19:02
@DouglasBarbin good point, I have updated my answer. I rely always on Convert.ToDateTime because I am sure that the text reaching there is a proper date (otherwise the calculations would be wrong anyway); but for general purposes and for this specific OP, who is not too experienced on VB.NET, I guess that this is a better solution. – varocarbas Jul 20 '13 at 19:07
@DouglasBarbin just to make completely clear this issue: people cannot trust TryParse (or equivalent) blindly as far as the goal is not avoiding an error, but having proper calculations. When you convert text into date, you have ALWAYS to make sure that it is a proper date before starting the date-related calculations. – varocarbas Jul 20 '13 at 19:10
TryParse actually returns a boolean value (true if the parse passed, false if it failed). So you would probably want to put it inside of a conditional, and set your variable to null if the TryParse fails. Then you can check the validity of your variable as needed. See my answer for an implementation of the general idea. – Douglas Barbin Jul 20 '13 at 19:32
@DouglasBarbin I have seen your answer and I did know already all what you are saying. The whole point of catching an error is letting the code continue. The problem is that if this variable is the input for the next calculation would provoke a crash anyway (later); even for displaying you cannot tolerate a wrong value. Thus, I use Convert.ToDateTime because I prefer to see any error poping up while developing and because no error-triggering situation will reach this part of the code. An example to illustrate my point better... – varocarbas Jul 20 '13 at 19:39
@DouglasBarbin If you input asdfasf-sd-45 in a code I have written, this text will not ever reach any date conversion part because of having in place a set of right-format checks which do not allow any invalid configuration through. Your code would allow this string going through but will catch it, no problem. For user inputs, it is more or less the same (well... an error catching is always slower); but if the input text dates are generated at runtime by a more or less complex algorithm, you might prefer to know exactly what is wrong at each second (out of space) – varocarbas Jul 20 '13 at 19:49
@DouglasBarbin I have taken your recommendation on board, because it has been a nice gesture from you to improve my answer. This is the main reason. If you ask me what I consider better, I wouldn't say TryParse. If you ask me to write the whole code (not just the interval calculation part) I wouldn't have done it as you did. I don't see a major problem with your code but I wouldn't recommend it either on top of other solutions; because of the two aforementioned reasons: allows faulty codes (not favorable to big developments) and is, by definition, slower. I hope that everything is clearer now. – varocarbas Jul 20 '13 at 19:55
You would nest any calculations you might do inside of that If statement in my answer. If the TryParse fails (and your myStartDate variable is null), you simply don't do the calculation and display an error message instead. In my opinion, it's better than throwing an exception and crashing the entire application. – Douglas Barbin Jul 20 '13 at 20:07
@DouglasBarbin see these two options: input = null try{string[] temp = input.split('.')} cath{} or if(input.trim().length > 0){string[] temp = input.split('.')} Both codes deliver the same. The first code would be slower. Now imaging a more complicated situation where the input has to be a124bcd88 (each position meets different conditions); for the try catch it is the same b124bcd88 than null (that is, a completely wrong input or just a partially wrong one). If you have set conditions determining if the format is right or not, you would have higher control (again out of space) – varocarbas Jul 20 '13 at 20:12
@DouglasBarbin don't get me wrong, try...catch statements have to be there but you cannot base your code of them. They are the last-option, the just-to-be-completely-sure alternative. I don't like relying on them by default as the normal flow of the code, to set up conditions or avoid a proper analysis of input values. I am not intending to convince you that this is a better programming approach, so don't intend to convince me of right the contrary (what on the other hand is pretty unlikely to happen :)). – varocarbas Jul 20 '13 at 20:16
@DouglasBarbin the code above is in C# but well... I guess that it is easily understandable (writing C# in line is easier than VB.NET). The basic idea is very easy: if you don't put a try catch in each single condition, why you think that has to do it when converting a text into date? High risky situations might be inside a try catch (like text to date conversion) but this is one thing and a completely different story is letting the error catching being a defining part of the conversion process. Well... I hope that, this time, my point is completely clear. – varocarbas Jul 20 '13 at 20:25
Your point is clear and I mostly agree with you. I am actually more familiar with C# than VB so no worries there. Anyways, I wasn't suggesting a try-catch for every condition, but you do want to be safe for those situations where type conversion might fail. – Douglas Barbin Jul 21 '13 at 00:21

OneFineDay · Answer 2 · 2013-07-20T18:44:41.673

0

The DateDiff function will do it.

label1.text = DateDiff("n", DateTime.Parse(EndTime.Text), DateTime.Parse(StartTime.Text)).ToString

If your app is crashing, did you check the variable you tried to pass to it? It looks like your trying to pass the textbox to it and not the textbox.text.

edited Jul 20 '13 at 18:44

answered Jul 20 '13 at 18:30

OneFineDay

9,004
3
26
37

Like I commented in the other answer, I usually prefer TryParse over Parse because there is no chance of an exception being thrown. It just feels "cleaner" to handle the parse failing through normal code execution rather than catching an exception. – Douglas Barbin Jul 20 '13 at 19:34
Me too, I was mainly pointing out the obvious type error they were using in the parameters. In their example the parsing would be fine since a Date object filled it. – OneFineDay Jul 20 '13 at 20:20

score 0 · Answer 3 · answered Jul 20 '13 at 19:00

Sub EndBreakClick(sender As Object, e As EventArgs)

    EndTime.Text = DateTime.Now.ToString()

    Dim myStartTime As DateTime? = If(DateTime.TryParse(StartTime.Text, myStartTime), myStartTime, Nothing)
    Dim myEndTime As DateTime? = If(DateTime.TryParse(EndTime.Text, myEndTime), myEndTime, Nothing)
    If myStartTime.HasValue AndAlso myEndTime.HasValue Then
        Dim someVariable As Long = DateDiff(DateInterval.Minute, myStartTime.Value, myEndTime.Value)
        ' DO SOMETHING WITH THAT VARIABLE HERE
    Else
        ' One or both of the textbox values wasn't a valid DateTime.  Display an error message or something
    End If
End Sub

Date and Time Difference in Minutes

3 Answers3