Comment On The Trouble with Blind Dates

The goggles, they do nothing!



....seriously, ouch.

Not sure, but doesn't the

if (date1 > date2) return 0;

fail to work with the new one-liner, 
I'm not sure how it's handled, but wouldn't it give positive and negative numbers of days?

Alex Papadimoulis:

    if (dat/100 == 2)

Was there an anonymization typo? Based on two dates I used to figure out the logic, I find that dat/100 cannot be 2 (it's always greater), but I guessed that daymo finds the number of days in a given month, in some convoluted way.

Well, that's a pretty, huh, creative way to do it... Maybe 5 minutes of research would've saved the poor sap days of creating this monstrosity.

>BiggBru

RTFM.

The first function has a bug... if the two dates passed straddle any of the following dates, the result will be off by one.

...
February 28, 1800
February 28, 1900
February 28, 2100
February 28, 2200
February 28, 2300
February 28, 2500
...

Note February 29, 2000 and February 29, 2400 are OK.

Thats the way you save your Job, nobody will understand your code,
once you're fired ;)

//captcha: clueless

Actually this function assumes every month is 31 days so it becomes grossly inaccurate the greater the span between the two dates.

Anonymous:

Actually this function assumes every month is 31 days so it becomes grossly inaccurate the greater the span between the two dates.

No. It handles the days per month mostly correct.

Anonymous:

Thats the way you save your Job, nobody will understand your code,
once you're fired ;)

//captcha: clueless

And they'll hire you back as a highly payed contractor.

If you put in 2 dates 1/1/2005 and 1/1/2006 you'll get 372 as a return value.  Which btw is the result of 12 * 31.

I'd like to see the reaction when the author is shown the replacement line of code.  Would he/she say "oops, I was stupid", or what?

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

The February "logic" has dat/100 and dat%100 switched, plus (as noted) it fails to implement the 100-year rule (granted you have to go outside 1901-2099 for that rule to matter).

I have no earthly idea how the April/June/September/November "logic" is expected to work.

a < 12 apparently imposes a maximum of 12 months (with wiggle room within the months, e.g. 1 May 2005 to 31 May 2006 gives 395 days), plus (as noted) there's a minimum of 0 days.  Was the original function named EffectiveDaysOverdue?

Anonymous:

Not sure, but doesn't the

if (date1 > date2) return 0;

fail to work with the new one-liner, 
I'm not sure how it's handled, but wouldn't it give positive and negative numbers of days?

I think the new one liner has a bug - should be date2 - date1.

ammoQ:

Anonymous:

Actually this function assumes every month is 31 days so it becomes grossly inaccurate the greater the span between the two dates.

No. It handles the days per month mostly correct.

...and in a very roundabout way. :)

(OK, I understand the author didn't know how to subtract two dates but there's no real excuse for not using arrays to find out the number of days in a month.)

Anonymous:

Actually this function assumes every month is 31 days so it becomes grossly inaccurate the greater the span between the two dates.

Well, no, the two lines that follow the initial appearance of daymo try to handle varying length of months in a year. I couldn't for the life of me understand how he reached such a complex setting though.

ammoQ:

It handles the days per month mostly correct.

Yup.  Mostly.  All the pieces are there.

-- first assume all months have 31 days
int daymo = 31;

-- february... in leap years, subtract two days; otherwise subtract three
-- this gets us to 29 or 28
-- note the leap year calculation is subtly incorrect (per my comment above)
if (dat/100 == 2) if ((dat%100 %4)==0) daymo -= 2; else daymo -= 3;

-- if the month is before August and even, or after July and odd,
-- subtract a further day (this is mostly correct)
if ((dat/100 % 2)==(dat/100 / 8)) daymo -= 1;
-- Oops... February now has one day too few (28 or 27)

Anonymous:

I'd like to see the reaction when the author is shown the replacement line of code.  Would he/she say "oops, I was stupid", or what?

I kind of think that the author would say something like:

"But MY code is more enterprisey!"



/captcha=billgates

biziclop:

ammoQ:

Anonymous:

Actually this function assumes every month is 31 days so it becomes grossly inaccurate the greater the span between the two dates.

No. It handles the days per month mostly correct.

...and in a very roundabout way. :)

(OK, I understand the author didn't know how to subtract two dates but there's no real excuse for not using arrays to find out the number of days in a month.)

It doesn't handle the days per month correctly at all.  As I said earlier it returns 372 as the difference between 1/1/05 and 1/1/06.

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

And no one who corrects grammar on a WTF forum gets "layed" [sic]

xix:

Not sure, but doesn't the

if (date1 > date2) return 0;

fail to work with the new one-liner, 
I'm not sure how it's handled, but wouldn't it give positive and negative numbers of days?

 

That's a known bug. The original coder wanted that line to be:

if (date1 > date2) return -(functionName(date2, date1));

But then he heard that recursion can blow your stack and couldn't figure out how else to do it.

--Rank

I've written something similar to that, except:
a) mine worked, and
b) the language didn't support it natively (no "Date" type).

Still, why didn't he use an array and then simply adjust for leap years? It's just weird not to do so.

Anonymous:

It doesn't handle the days per month correctly at all.  As I said earlier it returns 372 as the difference between 1/1/05 and 1/1/06.

Oooooooops, you are right. I didn't test it, just looked over it and saw "well, there is some code that seems to handle the days per month". But there are some bugs (e.g. / instead of %) that break it.

I've have yet to see a modern language that can't convert date structures to UNIX-style timestamps.  Comparing that way is simply (timestamp1 - timestamp2) / (60*60*24).  Use integer division, rounding, or casting to int as appropriate.

obfuscation, eh?

Anonymous:

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

And no one who corrects grammar on a WTF forum gets "layed" [sic]

Now That is funny!  (sadly true, too)

ParkinT:

obfuscation, eh?

http://thedailywtf.com/forums/post/43762.aspx

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

ammoQ:

Anonymous:

It doesn't handle the days per month correctly at all.  As I said earlier it returns 372 as the difference between 1/1/05 and 1/1/06.

Oooooooops, you are right. I didn't test it, just looked over it and saw "well, there is some code that seems to handle the days per month". But there are some bugs (e.g. / instead of %) that break it.

You fail to realize that the Kepezinskas calendar has 172 days.

Maybe this is another case of being payed (as well as layed) by the line.  And who can really trust the built in date calculations?  If you want to be REALLY sure...

If the calendar ever changed (once the terrorists take over the world) his code will be easily (well not quite) maintained and my date2 - date1 will need extra code to compensate for the changes.

date3 = Math.AdjustForTerrorists(date2,date1)

 

The first rule of writing your own date manipulation functions is: don't write you own date manipulation functions!

How people don't get it? This should taught in schools instead of starting the teaching of OOP with implementing simple class Date (quite common example indeed).

I'm wating for the day, when people eventually understand, that our calendar system really sucks. Why are we still using this ancient stupid "you have to remember how many days there are in each month"-calendar?

I always call my return values ret.
The name of the function is a good clue to what the value means, but is usually far too long to type.

Sure, let's start using Star Dates instead :)

The fun thing is that every so often, due to the imperfections of the alignment of the sun, moon and the earth, we need to have leap years, seconds, etc. so there's still quirks, but at least it wouldn't be such a hard thing to remember in comparison, and math on dates would be simpler, until you start getting picky and dealing with the occasional leap second, etc.

nene:

The first rule of writing your own date manipulation functions is: don't write you own date manipulation functions!

How people don't get it? This should taught in schools instead of starting the teaching of OOP with implementing simple class Date (quite common example indeed).

I'm wating for the day, when people eventually understand, that our calendar system really sucks. Why are we still using this ancient stupid "you have to remember how many days there are in each month"-calendar?

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

Oops. (Although English is not my native language, it's understandable that things like this do happen if I'm not paying attention to what I write. :))

what an amazing construct. truely the most deserving wtf I've seen in a long while. we all do this from time to time on a smaller scale, but the perserverence it must have taken to see this one through is bewildering. while I accept that I am stupid and have limited capacity for these things, this guy is a wtf-y genius and I must bow to his clever idiocy.

the only thing I could think when I read the code was indeed "w.t.f????". more like this please.

Using unix time_t and taking the difference / (60*60*24)  will be slightly wrong because of leap-seconds.  The library functions that gave you the time_t will have taken leap-seconds into account.

Anonymous:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

Why? If you already know what the function returns (e.g. from the comments), it would be redundant to state it in the variable name.

Anonymous:

Eq wrote the following post at 06-01-2006 2:57 PM:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

I always call my return values ret.
The name of the function is a good clue to what the value means, but is usually far too long to type.

Score 1 for Visual Basic?

Anonymous:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

Hey, have you been looking at my code again?  You can tell it's mine because it's called 'PROGRAM.EXE'.

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

Someone who doesn't understand double negatives, shouldn't discriminate on "paid" versus "payed".

Anonymous:

Using unix time_t and taking the difference / (60*60*24)  will be slightly wrong because of leap-seconds.  The library functions that gave you the time_t will have taken leap-seconds into account.

IIRC, the definition of Unix time values requires that leap seconds are ignored - each day is treated as though it lasts exactly 86400 seconds (even if it isn't really). Simplifies things a lot...

biziclop:

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

Oops. (Although English is not my native language, it's understandable that things like this do happen if I'm not paying attention to what I write. :))

 

Ah.. you're forgiven then, and I'm sorry!

foobish:

Anonymous:

biziclop:

And they'll hire you back as a highly payed contractor.

 

No one who can't spell "paid" deserves to be highly "payed".

Someone who doesn't understand double negatives, shouldn't discriminate on "paid" versus "payed".

Your comment on double negatives is the least benightedly unintelligent one it has ever been my extreme displeasure not to be able to avoid reading.

Mostly is the keyword here :-)

The comments probably say the code is "Mostly harmless".  This is a great improvement over the first version of the comments, which simply read "Harmless".

Anonymous:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

I use it.  In a language which does not have the return value in a variable of the same name as the function, it serves the same purpose.  All I want to state is that the variable is the return value under construction.  That makes "retval" a good name (for me).

Sincerely,

Gene Wirchenko

jesuswaffle:

Anonymous:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

Why? If you already know what the function returns (e.g. from the comments), it would be redundant to state it in the variable name.

Gene Wirchenko:

I use it.  In a language which does not have
the return value in a variable of the same name as the function, it
serves the same purpose.  All I want to state is that the variable is
the return value under construction.  That makes "retval" a good name
(for me).



Sincerely,



Gene Wirchenko

You'd think so.
But.

Compare it to a short story, with a most fitting title and comfortably descriptive introduction, but the actual story comprising mostly of sentences such as "When that thing happened at that time with the thing."

The syntax is for the compiler. It doesn't complain.
The code itself is for us. Programmers do.

Anonymous:

I'd like to see the reaction when the author is shown the replacement line of code.  Would he/she say "oops, I was stupid", or what?

It could be telling.

I am just working on some code where I have to say that the way that it was was a good idea at the time.  At least, I hope it was.  Sometimes, that previous idiot who was working on the code is you, well, me.

Sincerely,

Gene Wirchenko

dhromed:

jesuswaffle:

Anonymous:

Ugh, I hate it when people use "retval" for a return value. You might as well call it "variable".

Why? If you already know what the function returns (e.g. from the comments), it would be redundant to state it in the variable name.

Gene Wirchenko:

I use it.  In a language which does not have
the return value in a variable of the same name as the function, it
serves the same purpose.  All I want to state is that the variable is
the return value under construction.  That makes "retval" a good name
(for me).

You'd think so.
But.

Compare it to a short story, with a most fitting title and comfortably descriptive introduction, but the actual story comprising mostly of sentences such as "When that thing happened at that time with the thing."

The syntax is for the compiler. It doesn't complain.
The code itself is for us. Programmers do.

Compilers are professional complainers.

Yes, we are even better/worse at it.

while programmer's sanity exists

"What is that variable for?   The one that you called '<some long name>'."  "Oh, that is the return value."  "Why did you not just call it 'retval'?"  "Well, dhromed said . . .  OK, I will change it."

"Why did you just call that variable 'retval'."  "Oh, that is the return value."  "Why did you not call
it '<some long name>'?"  "Well, Gene Wirchenko said . . .  OK, I will change it."

end of while

Sincerely,

Gene Wirchenko

After skimming the thread, I would like to make a couple observations:

1) I'm assuming that the "punctuation" got messed up during anonymization, and that the orignal code actually worked...  But hey, who knows...

2) The difference between "paid" and "payed" is spelling, not grammar.

3) Clearly the right way to perform this operation is data-driven :)

 

short isValidDate[99991232]; // fix the y10k bug later

/* load in data that populates our array... probably from some sort of XML file... the first 10101 elements are 0, then the next 31 are 1, then 69 more 0's, then 28 1's... you get teh idea, right? */

d = 0;

for(i = d1; i < d2; i++) {d += isValidDate[i];}

BAM!