- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Ouch! Those hurt.
(Good article.)
Admin
Date and time handling is hard, lets make it harder.
TRWTF is contracting to solve a problem which has already been fixed... Several times.
Admin
Lines like that make me somehow happy that as I get older they're harder to read.
Admin
I wonder if the application crashes and burns if someone tries to schedule a 9AM meeting...
Filed under: Sounds like a feature, '9' > '10'
Admin
I'm not going to try to decipher that (not my job). But I'd say you should convince them to buy something off the shelf. MS likely has a number of products that do what they want. Cheaper than contractors and having someone in house to maintain it.
Admin
Can we get something done about the CSS on those code blocks?:
[image]Admin
Norepro on Chrome, Win 8: [image]
Admin
FF34.0.5/Linux here.
Admin
Repro on FF 33.1 Win 8 [image]
Admin
repro on FF(android): [image]
Admin
I was looking at a totally different image just now. Did you or Discourse do something weird?
Also, the code wraps on Chrome but not on Firefox on my Ubuntu laptop.
What does IE do?
Admin
I doubt this helps any, but I tried to make these lines a little more readable.
And
Admin
That doesn't really reduce the :scream: very much.
Admin
It should probably use
white-space:normal
for the<pre>
tag. I guess Chrome automatically fixes this but not Firefox...Admin
Or anything that doesn't start on the hour. Oh, that 8:30 meeting you have? Sorry you have to change it to 8 or 9.
Admin
The second one is misleading because of the parens not being matched correctly. I personally format it like this:
The first statement looks for any meetings that start before and end after a given meeting The second statement looks for meetings that start during and end during a given meeting The third statement looks for meetings that start before and end during a given meeting The last statement looks for meetings that start during and ends after a given meeting
Admin
That fixes it for me.
Admin
I think there are an awful lot of people out there who somehow get into SQL without any proper training, and learn it through looking at the queries generated by Access. These are a whole world of pain on their own but looking at some code, there are obviously people who think that is the right way to do things. The absolute worst case I have ever seen was a single SQL query that ran to 3.6Mbytes - yes, that is megabytes - because hard coded case by case exceptions were written into the query rather than fix the data in the database (even a suitably designed view could have done it.) Oddly, the performance wasn't very good.
My favorite WTF, though, is that SQL Server didn't even have Dates till 2008, creating really annoying portability issues. Because sometimes you really do want to bound epochs to a day (when for instance you are selecting date ranges from tables with millions of records and an efficient query is needed). Absence of Dates allows programmers to store stuff in ways that require inefficient queries - though not as bad as the one in the article.
Admin
I think I have yet to see the case where a dedicated Date type would prove to be a significant improvement over a DateTime with time portion zeroed. They're all probably represented by some sort of integer timestamp, and comparisons don't really look whether your range of values is sparse or not.
Admin
Have you actually tried this on a big data set? In fact SQL Server does not store datetime as an epoch, but as two 32 bit integers. The date integer is based on 1/1/1900, the time integer as from midnight. Oddly, time is stored in intervals of 1/300 sec, not milliseconds. For comparison the two integers could be treated as a 64 bit integer since the concatenation is monotonic. But a Date is stored as a single 24 bit integer. If I wish to use an in-memory table as an index to extract the primary keys of rows which fall in a date range, given that for various reasons the primary keys may not be monotonic with respect to the date, the in memory table using datetime is bigger even if an internal optimisation treats datetime comparison as a 64 bit integer compare. I am not about to go and test this but I would expect that the performance hit would be smaller on a 64 bit machine than a 32 bit machine. Even so, there is a difference due to the limited I/O speed of disk operations.
Admin
I too have worked for a CEO who supposed that a problem which had been fixed by a large team of people and then been optimised and improved over years could somehow be done better by a couple of new grads in six months. Programming is obviously a lot easier than customer schmoozing.
Admin
Sending work out to a consultant, what could possibly go wrong?
Admin
I just submitted a bugfix.
https://github.com/tdwtf/WtfWebApp/pull/116
Admin
PHP - bah!
Admin
@Remy just accepted it; hopefully that fixed it.
Admin
...which obviously can be all summarized as a single case: meetings which start before the given meeting ends and end after the given meeting start
As to the first snippet of code (the allegedly PHP one), I doubt it even parses correctly, as there is an identifier
meetings
right after an array subscript operator.Admin
Yeah, you get code like that, when looking for range overlaps, if you don't know the secret I discovered.
To determine if two datetime ranges overlap:
Looks stupid but it works. "Well, Coyne, how did you arrive at that?"
Well, first of all, it does require that the ranges be "normal", such that RANGE.START <= RANGE.END, always. Then, start with a WHERE clause that proves two ranges don't overlap:
It should be obvious why that works. There's only two possible cases: RANGE1 comes before RANGE2 or vice-versa. Now, to get ranges that overlap, just...
If the previous version found ranges that don't overlap, this one finds ranges that do. Obvious, right?
Now, to get rid of the NOT, apply DeMorgan's laws:
Combine to yield the original WHERE clause, for normal ranges.
Now, of course, storing the time in a VARCHAR...well, that is beyond help.
Admin
Whoo-hoo!
Admin
Thank you for typing all of that. Doing so made it much easier for me to analyze it.
As best I can determine, the SQL is correct. It is, of course, excessively complex. And it has a few more parenthesis than it needs -- even discounting order of operations.
Formatted and commented:
Admin
That reminds me ...
A former co-worker of mine didn't know that you could check for overlaps like this. So he wrote things the hard way everywhere and - of course - forgot to handle the case where one of the timespans is fully inside the other one. That was awful.
Admin
Did someone say centered interval tree?
Admin
While this does fix the linebreaks the code is still not shown correctly, because the first < is used as the start of a html tag...
Admin
Has been my daily work for the last 4 weeks...
Admin
Admin
Am I TRWTF or is something wrong here? Range 1: 8am - 9am Range 2: 10am - 11am
Range1.end = 9am < range2.start = 10am Statement returns true, overlapping is false.
Admin
Heh...I hadn't looked closely, but he reversed it (either put the starts as the first arguments or use greater than).
Admin
I'm not sure you can do it in one statement. If a meeting is entirely later than another meeting, that meeting's end is after the other meeting's start, but they don't overlap. You need two statements to determine overlap, don't you? With an AND, not an OR. I guess if you were fancy and used an XOR it might work...
Admin
Wait...now I'm looking at what you quoted, and it's your quote that's wrong. I'm not sure what's going on, but I think IHBT. :trollface:
Admin
what about this?
to my mind, assuming we have a cross join (value will eventually be in both RANGE1 and RANGE2) that should find overlaps
of course i'd have to sit down with pen and paper to prove it.....
Admin
huh?
Not wrong
whjich is what I quoted:
OH! Reading comprehension fail on my part. That test is to prove they do NOT overlap.
Admin
Yes, I got confused by my own lack of close reading, and didn't realize that you'd quoted the "non overlap test." And then I started typing...
Admin
hmm.... ditto.
whoopsies?
Admin
I started writing my own and damaged my brain something fierce. I think it's the association of GT/LT with earlier/later that my brain refuses to acknowledge. I'd have to do it on paper and I'm not putting that much work into a forum thread XD
I can write test cases though:
CASE 1: Range1: 9am-10am Range2: 11am-noon Expected output: NO OVERLAP
CASE 2: Range1: 11am-noon Range2: 9am-10am Expected output: NO OVERLAP
CASE 3: Range1: 9am-noon Range2: 10pm-11pm Expected output: NO OVERLAP
CASE 4: Range1: 9am-noon Range2: 10am-11am Expected output: OVERLAP
CASE 5: Range1: 9am-noon Range2: 10am-1pm Expected output: OVERLAP
CASE 6: Range 1: 9am-noon Range2: 8am-10am Expected output: OVERLAP
Admin
Admin
Trying to figure out if this would work in T-SQL...
Admin
assuming SQL2012 and appropriate data types.... yes.
unsure about older versions.
Admin
I usually develop with 2008.
Admin
in that case it probably works with 2008 as well. i don't have that version in front of me to test and can't be arsed to look up the syntax on MSDN.
Admin
Admin
hmm... let's see.....
0700 <= 0800 && 1000 >= 1100 ==> FALSE 0800 <= 0700 && 1100 >= 1000 ==> FALSE
huh... you're right. my solution catches overlapped appts but not an appointment completely contained by another appt.