• Tim (unregistered)

    The goggles, they do nothing!

    ....seriously, ouch.

  • xix (unregistered)

    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?


  • AA (unregistered)
    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.
  • (cs)

    <FONT face=Georgia>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.</FONT>

    >BiggBru

  • diaphanein (unregistered)

    <FONT size=6>RTFM.</FONT>

  • Maurits (unregistered)

    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.

  • phlox (unregistered)

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

    //captcha: clueless

  • Wm (unregistered)

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

  • (cs) in reply to Wm
    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.
  • (cs) in reply to phlox
    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.
  • Wm (unregistered) in reply to ammoQ

    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.

  • David Walker (unregistered) in reply to Wm

    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?

  • David Walker (unregistered) in reply to biziclop

    biziclop:

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

     

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

  • (cs)

    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?

  • ChiefCrazyTalk (unregistered) in reply to xix
    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.

  • (cs) in reply to ammoQ
    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.)
  • (cs) in reply to Wm
    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.

  • (cs) in reply to ammoQ
    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)
  • LizardFoot (unregistered) in reply to David Walker
    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
  • Wm (unregistered) in reply to biziclop
    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.
  • YourName (unregistered) in reply to David Walker
    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]
  • (cs) in reply to xix
    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:

    <FONT face="Courier New" size=2>if (date1 > date2) return -(functionName(date2, date1));</FONT>

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

    --Rank

  • (cs)

    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.

  • (cs) in reply to Wm
    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.
  • (cs)

    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) / (606024).  Use integer division, rounding, or casting to int as appropriate.

  • (cs)

    <FONT face=Verdana size=6>obfuscation, <FONT size=3>eh?</FONT></FONT>

  • (cs) in reply to YourName
    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)

  • navision (unregistered) in reply to ParkinT

    ParkinT:
    <FONT face=Verdana size=6>obfuscation, <FONT size=3>eh?</FONT></FONT>

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

  • Eq (unregistered)

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

  • (cs) in reply to ammoQ

    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)

     

  • (cs) in reply to ParkinT

    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?

  • retman (unregistered) in reply to Eq
    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.
  • Jonathan Thompson (unregistered) in reply to nene

    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?

  • (cs) in reply to David Walker
    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. :))
  • some moron (unregistered)

    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.

  • pastor (unregistered)

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

  • (cs) in reply to Eq
    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.
  • (cs) in reply to retman
    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?

  • (cs) in reply to Eq
    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'.

  • (cs) in reply to David Walker

    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".

  • (cs) in reply to pastor
    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...

  • David Walker (unregistered) in reply to biziclop
    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!

  • (cs) in reply to foobish
    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.

  • (cs) in reply to ammoQ

    Mostly is the keyword here :-)

  • (cs)

    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".

  • (cs) in reply to Eq
    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

  • (cs) in reply to jesuswaffle
    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.
  • (cs) in reply to David Walker
    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

  • (cs) in reply to dhromed
    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

  • The Anonymous Coward (unregistered)

    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!

     

Leave a comment on “The Trouble with Blind Dates”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article