Ok, finally

Always fun to get five yellows

Meanwhile

Robbed of a 3!

Welp that's a first. Someone whose Post I commented on, tried to add me on LinkedIn today lol. Have a good weekend peeps.

This is fine meme becomes reality in a restaurant in Saint-Étienne in France (this week during protests).

twitter.com/i/status/1637957772896509956

@JohnK.N. I get "sorry this video can only be watched within Switzerland"

oh, but the Twitter video works

scary

i used my vpn to watch it

that skull looks better on my dark mode visual studio code

Just saw "The Ballad of Buster Scruggs". What an amazing and thought-provoking movie

Double rainbow all the way

Noiceee

@PaulWhite So it's faster to use DATETRUNC because it returns the same data type you give it, whereas CAST AS date needs to convert back to datetime2 again because DATEDIFF doesn't accept date, correct? Interesting that the query plan doesn't show any of this conversion dbfiddle.uk/QAuVai8W (but not hugely surprising, we know it's only a vague indication of what's actually going on)

@J.D. That's basically what I was getting at. It only makes sense to have it that way if you want a fixed length result, and probably a fixed length input also. It is still possible to right align it to a fixed length using binary concatenation if it's variable length, just more complex dbfiddle.uk/whBh0vYi

@Charlieface You're headed in the right direction but seem to have confused some of the details (like datediff v dateadd). Certainly how dateadd or datediff are implemented at the lowest levels is not visible in execution plans. They could have surfaced that I suppose but it would likely have a performance impact to perform all the conversion steps higher up

Meant to say DATEADD there soz

The docs are interesting. They say it accepts any date type, but a string must be comvertable to datetime. Doesn't sound very accurate

Indeed the documentation is not universally infallible or comprehensive. Even where it was at some stage, it's not always maintained every time a product change occurs

The (relatively recent) explosion of date & time types and precisions no doubt made specific optimisations more difficult. I can quite see the attraction of converting most cases to max precision datetimeoffset for the calculation stages with a final rounding and cast to the target data type

From 644 where I started with EMAIL

@PaulWhite That's one of the most frustrating patterns to get into.

I've missed the word entirely in a situation like that before.