Sergiy (3/5/2013)
Steven Willis (3/4/2013)
As for the time being bound to the date...well, no, not in this case. As I pointed out in the OP the data I'm getting from the application is actually in the form "10:35","14:22", etc.Oh, really?
There is no any "ConnectDate" in the same row?
And you cannot tell on which day that "ConnectTime2" has happened?
Sorry, I find it very hard to believe.
Because when Verizon charges a customer for the calls they summarize all call durations for a month, so they have to know on which day any particular connection was established and on which day it it was ended.
So please, do not tell anyone that the application stores only times with no dates. Because it's simply - not true.
Whatever...
These values "10:35","14:22", etc. are from an HTML form and they are posted as strings generated by a hard-coded HTML dropdown with the 5 character pseudo-"time" values as an option item in the select input. So they are just numeric-looking character strings until someone (me) does something with them. The list of "times" is not dynamically generated as the HTML form is just a static hard-coded form.
Now I wrote in my post above that I know the date these values apply to, but that date (also a string since this is HTML we are talking about) needs conversion also and I COULD IF I WANTED TO concatenate the date and the times to create a well-formed datetime value but as you have correctly surmised the date itself IS stored in another column already. As for the "time" column all I wanted to do was give the "times" back to the application in a manner that they would sort as time and not in ASCII sequence and allow me to determine durations between the values. I just didn't need to bother with the date-part nor did I care about the date-part since all of the time values in a particular batch ALWAYS belong to the same day. (Golfers don't have tee times that cross midnight into the next day. Maybe if the course was in the arctic I'd have to worry about that.)
The post was originally made to show that there are rare cases like this where the date part doesn't matter. If that wasn't the case why would Microsoft have bothered creating a TIME datatype? I don't know what your issue is. I made an observation concerning a situation I encountered and if you never face such an issue then I guess the whole point is moot. I don't want to argue about it.