Just in case we tear the fabric of spacetime



  • In some deep dark corner of our framework code... actually, in a method that gets called on nearly ever page load...

    if(now<dateTime1)
    {
    // coming soon
    ...
    }
    else if(now>dateTime1 && now<dateTime2)
    {
    // active
    ...
    }
    else if(now>dateTime2)
    {
    // closed
    ...
    }
    else
    {
    // who knows what time it is
    ...
    }

    The time when we reach the else clause is, ironically, quite easy to figure out.



  • I think it was last Thursday night, my bedroom light flickered, and the cat seemed a bit upset. I new something like this was bound to have happened.



  • Not knowing how dateTime1 and dateTime2 are calculated, it's hard to say what would happen.  If all 3 values are identical, the else can be reached.  What do your unit tests look like?



  • Also, if now is dynamic, rather than simply a variable set earlier (it's difficult to be sure of the language here) all sorts of odd things could happen!



  • Actually the else gets reached if now() equals either time, dateTime1 and dateTime2 don't need to be identical.



  • @nerdydeeds said:

    Not knowing how dateTime1 and dateTime2 are calculated, it's hard to say what would happen.  If all 3 values are identical, the else can be reached.  What do your unit tests look like?

    Hah! Unit tests! Of course, dateTime1 and 2 are start and end dates, respectively. I should post more of the code that this chunk came from because it just exudes WTFery.


  • Considered Harmful

    What if dateTime1 > dateTime2?  It seems just WTFey enough to make me think that that constraint isn't actually enforced...



  • Well, they do try to enforce some constraints in other parts of the code. The key word there, of course, is "try." They fail.

    They check to see if the column from the database containing a start date equates to an empty string, and if not, they assign the value to a DateTime object that is declared [i]inside the if block[/i], and then promptly thrown away as that is the only statement inside. Then they go on to parse the same date three more times wherever it is needed. The code I posted was the rare case where they actually abstracted the column out into a variable properly (although without checking this time).



  • @joe.edwards@imaginuity.com said:

    What if dateTime1 > dateTime2?  It seems just WTFey enough to make me think that that constraint isn't actually enforced...

     
    Leaving all other assumption aside it wouldn't matter if dateTime1 > dateTime2 as long as the now<dateTime1 block is still valid. It would just mean it's never active.



  • Um, and what if now == dateTime1 or now == dateTime2? Remember that ab can fail simultaneously if a==b, so they're not mutually exclusive.



  • @yafake said:

    Um, and what if now == dateTime1 or now == dateTime2? Remember that ab can fail simultaneously if a==b, so they're not mutually exclusive.

    Congratulations.  You've found yet another WTF in the forum software.



  • @Carnildo said:

    @yafake said:
    Um, and what if now == dateTime1 or now == dateTime2? Remember that ab can fail simultaneously if a==b, so they're not mutually exclusive.


    Congratulations.  You've found yet another WTF in the forum software.


  • What time is it? I'm glad you asked...



  • @Volmarias said:

    What time is it? I'm glad you asked...

    Sigh... it looks like PLIF has some sort of retarded "how dare you link to our images" policy. Copy/paste the url into a new tab, and it will work fine :(



  • Sigh... it looks like PLIF has some sort of retarded "how dare you link to our images" policy. Copy/paste the url into a new tab, and it will work fine :(

    Not for me, I just get a blank screen. FF2, if it matters. 


Log in to reply