How do I add minutes to a time data type?

This question has spontaneously devolved into an edit war. The author feels slighted. Here is his "closing volley" and then my ruling as a moderator (hey, I'm just cleaning up stuff).

Final notes:
It is my right, as the person who asked the question, to determine if the the question has been answered in a satisfactory way. At this time I do not feel that there is an answer which fully answers the question I am trying to ask.

There is a lot of other information, which can be seen in the history link on the Q, but I'm here to settle the dispute over content, not the technical accuracy of the answer. So, if you're ALL with me and understand that that is the POINT of this post, then we shall begin.

It is indeed the author's right to determine accuracy. However, as the author, you don't get to retroactively say "oh, you absolutely didn't read my mind and answer what I needed." To wit: Trisped should have considered this portion:

A correct answer should contain the following information:

  • How to add minutes to to a time data type.
  • That the proposed solution does not result in a loss of precision.
  • Issues or concerns to be aware of in the event that the minutes would be to too large to fit in a time variable, or risk of rolling the time variable over. If there are no issues then please state so.

When he asked the question. Now, that being said, that's a little insensitive of me to say, because sometimes we have to ask the question and have some discussion over what makes it a great question. I don't see any such back and forth, but we can chalk it up to "I re-read the question and this seems to be missing". That's fair. Given the new requirements (which I have a technical answer on, but which this forum is not for technical accuracy but for the running of the site, it being meta, let's keep it to the asking of questions and giving of answers) the answer still seemed valid. So what's up with the rant?

The rant says "Oh, Aaron changed two of my "record" to "row", woe is me". Yes Trisped, I am using sarcasm to make light of the rant. The issue is that apps use records, database tables store records as rows. When discussing query, the technical term is row. You don't get to change that. What you display on screen is a record. Learn the differences in terminology, because your entire programming career will be filled with this sort of nuance. He also removed a comment which was superfluous and didn't add to the conversation, as I've never had rowcount interrupt my query results before. To be honest, I forget how much value it even is anymore. But the point being, when someone with Aaron's expertise removes a comment from a query that he sees as superfluous to the discussion of answering your question, that's not something to get pissy on.

So Trisped, consider your hand smacked at this point, for the following:

  • Starting an edit war with a moderator (Jack Douglas) who reverted your edit and asked you to not do that,
  • Arguing with people who are trying to tell you what the proper operation of the requested function are,
  • Being highly pedantic about the edits of your question without working to engage better clarification of the question.

And with all that said, I feel like if you stay with the network (this sort of thing is the reason people leave the network, but that's a shame) then I think you'll make a great going-forward user of our network. You obviously want to know this stuff, and that's highly important. Don't give up on us yet, just learn that others can edit your stuff and that that's ok! That's all you have to do to earn my blessing, and this whole thing just goes away.

Aaron Bertrand:

You get your hand publicly slapped for deleting your great answer, and for arguing when this should've become a moderation issue, and for your pissy comments (like I haven't left literally dozens of those, so I know I'm absolutely not pure in this case, but I still get my hand smacked, and often).

Thank you for not continuing an edit war, and for being mostly calm.

To everyone else:

Thank you for not getting into an edit war, and for not destroying the basic thread of what's going on here.

What happens now:

If there are actual merits of answering this question to be discussed that aren't technical solutions, then now is the time for Trisped to respond with an answer. He can even rant and rave here, if he likes, because that's what this post is about. However, that will NOT bleed over to the main DBA.SE, this has become a site-operation issue, and not a post editing issue.

| |
  • 2
    FWIW the way DATEADD works with TIME is that it simply rolls over at midnight, and over and over again, so DATEADD(MINUTE, 1000000, @sometime) is equivalent to DATEADD(MINUTE, 1000000 % 1440, @sometime) - at least in SQLFiddle with SQL Server 2012 – Cade Roux Jan 11 '13 at 21:11
  • So you use a DateTime, because then you can detect day rollover, and you just extract the time, but these are all technical discussions :p – jcolebrand Jan 11 '13 at 21:13
  • @jcolebrand his point is that if you only care about the time, you don't need to use datetime. – Aaron Bertrand Jan 11 '13 at 21:16
  • bah, anytime you add even a second to a time, you have to monitor date. Anybody who understands time addition has to see that. 23:59:59 + 00:00:02 => ??? – jcolebrand Jan 11 '13 at 21:17
  • 1
    @jcolebrand I may be wrong but I never saw anything about how he actually wanted rollover to be handled. The BIG problem is when only the end time rolls over and not the begin time. Then you can't get the interval with DATEDIFF without reversing the order AND subtracting from the number of units in the day. – Cade Roux Jan 11 '13 at 21:18
  • 1
    @CadeRoux which becomes "question clarification" which should've happened in the first place. We learn, we move on. We're doing that here. – jcolebrand Jan 11 '13 at 21:20
  • 2
    I did talk about that in one of the comment streams that has since been purged. – Aaron Bertrand Jan 11 '13 at 21:24

Trisped seemed to get angry for a number of reasons:

  • I changed two instances of record to row, but overlooked a third. I did this only as an addendum to two other edits (removing the comment, but I removed it not for the reason you suggest, but rather because it coerced horizontal scrollbars on the code sample) and the addition of the word that to make one of the sentences more coherent. I don't think the outcome would have been any different if I had caught all three instances of the term, since that was a substantial part of his complaint on multiple occasions, but who knows? The reason I changed that word is because, as you suggest, the widely observed correct term for a "record" at rest is a row. Record makes me cringe unless we're talking about vinyl or Access (well, I still cringe there too).
  • I suggested an approach that he had allegedly discarded before asking the question, because (again allegedly) he didn't think it would work. He failed to include that information in the original question, but made a big stink about it afterward - to the point of demanding that I add some context to the answer around the fact that DATEADD and TIME play nice, holding his accept as hostage until I do so.
  • He had some kind of hangup about potential loss of precision, and demanded that be included in my answer as well, even though it was not disclosed as a concern in the question. For this he could have simply tried the code that I provided and determined that there would be no loss of precision.

Ultimately, he got his answer, so I'm not sure why he got so uppity and downright unappreciative about it.

But I still feel like the question should be closed and discarded. Again, Trisped got his answer, and the question is unlikely to help many future visitors that will have the same misconception about (or lack of willingness to try) DATEADD before posting.

| |
  • 3
    I agree that it's unlikely to help anyone in the future, as the MSDN right thing to do is DATEADD. – jcolebrand Jan 11 '13 at 21:28
  • The reason I changed your edit back was because you said I could, because of the inconsistency, and because every definition I could find indicated that the correct term was "record". – Trisped Jan 11 '13 at 21:43
  • I do not remember saying that I would not edit my question as you requested. I do remember saying that if you added the part about return type I would accept it and I do remember you indicating that I would have to edit my question first. Right after that everything was side tracked by your quote from Celko. I was under the impression that we were negotiating, not making demands. – Trisped Jan 11 '13 at 21:46
  • 1
    @Trisped And I tried to explain that what you found and what most industry experts tend to agree on are two different things. <shrug> If your main problem was the inconsistency (as I said, I overlooked one instance of record), we could have just as easily changed the third instance to row. It does not look good for you to get into an edit war with a high-rep user and a moderator. – Aaron Bertrand Jan 11 '13 at 21:49
  • As I indicated in my question this morning, if you have an official source for "what most industry experts tend to agree" then I would be pleased to have it. – Trisped Jan 11 '13 at 21:55
  • 1
    @Trisped the change is accurate. I still question what this has to do with DATETIME, TIME, and DATEADD precision. – swasheck Jan 11 '13 at 22:02
  • 1
    I am a bit confused on your comments. How should I interpret "And I tried to explain that what you found and what most industry experts tend to agree on are two different things." with "... a record and a row are not the same concept, even if they are confused / deemed interchangeable by a large portion of the industry?" and the fact that I believe that I was talking about a record, not a row (I know they are not the same)? – Trisped Jan 11 '13 at 22:05
  • 2
    Having said that, here's a citation: Itzik Ben-Gan, et al., Querying Microsoft SQL Server (Sebastopol: O'Reily, 2012), pp. 10-11. The relevant section starts with "Your use of terminology reflects on your knowledge." – swasheck Jan 11 '13 at 22:05
  • 1
    @Trisped it's your world and we're just playing in it. What would you consider "official?" – swasheck Jan 11 '13 at 22:07
  • 1
    @swasheck I suspect he wants something on the Interwebs, none of this fancy printed book stuff. – Aaron Bertrand Jan 11 '13 at 22:25
  • 1
    @Trisped Ok, hmm.. English is only my fourth language right after TSQL, Delphi and Swedish but you did write "inserts two records into a table" and that would make them rows right? or? – Mikael Eriksson Jan 11 '13 at 22:39
  • 2
    ENOUGH WITH THE DISCUSSION OF ROWS VS RECORDS. – jcolebrand Jan 11 '13 at 22:39
  • 1
    @Trisped the clarification of questions occurs in the comments. Not in edits. – jcolebrand Jan 11 '13 at 22:41
  • 1
    @jcolebrand: I would partly challenge that assertion: clarification of questions occurs in the comments. Not in edits. All relevant information should to into the question, not into comments. But you shouldn't change the question to something else, especially after answers have been given. I quote the FAQ: If other users ask you for more information in the comments, edit your question using the edit link just below your original question. – Erwin Brandstetter Jan 12 '13 at 0:15
  • 2
    Not to resurrect a dead thread, but I think I understand what Trisped is trying to say. His comment states that inserting to a table creates rows, but the object that you are inserting the data from is a record, which seems consistent with the answer that jcolebrand posted to the question that Aaron asked about this. It follows, then that this argument is about whether the subject is the object that data is being inserted from, or the object in the table after the insert, which is a much worse argument than defining row vs record. imho. – SeanVDH Jan 17 '13 at 14:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .