• JoeBar (unregistered)

    To get this started:

    if ( comments <= NO_OF_SECOND_COMMENT ) return "first";

  • Man of Steel (unregistered)

    One more time bug and I'm calling for a general strike. Let's all switch to POSIX time already.

    Q: What time is it?

    A: 1244466496

    Q: When do you want to have lunch?

    A: About 1244480000 work for you?

  • Addison (unregistered) in reply to Man of Steel
    Man of Steel:
    One more time bug and I'm calling for a general strike. Let's all switch to POSIX time already.

    Q: What time is it?

    A: 1244466496

    Q: When do you want to have lunch?

    A: About 1244480000 work for you?

    give us a couple hundred years to integrate with our machines and that should be perfectly reasonable.

  • Bobble (unregistered)

    Protip: You don't have to wait until a Feb 29th to fix this bug.

  • Mark V Shaney (unregistered)

    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

  • buja (unregistered)

    puts c++ beard on

    • no include guards, which is especially great when using so many #defines

    • expects that someone puts a global "using namespace std;" before including time_help.h (or spreads specific using directives like "using std::cout;" etc. around)

    • no "inline" linkage, so multiple source-files #including time_help.h will result in multiple definition errors

    • mixing floating point with integer calculations without proper cast and relying on compiler specific behaviour

    • "#define SECpYEAR 31536000" some lines later "#define YEAR time(NULL)/31536000+1970" --> yay for still using magic numbers --> double yay for for not putting the definition in round braces

    Oh that code is so great. But regarding that it's not even 2^8 lines long, why not just rewrite instead of fixing?

  • (cs)

    "int dateformat;" and "int YEARSCOPE;" in header file is a very clever solution - each .c file can use its own time format and yearscope (whatever it means).

    I like that the month length is a random variable with value (almost correct) of expected value in randomly taken month (AVGDAYINMONTH 30.4375). Although 

    #define AVGDAYINMONTH (0.25365.0/12.0 + 0.25365.0/12.0 + 0.25365.0/12.0 + 0.25366.0/12.0)
    would not be so optimized.

  • Man of Steel (unregistered) in reply to Bobble
    Bobble:
    Protip: You don't have to wait until a Feb 29th to fix this bug.
    Managertip: The return on investment of fixing the bug now is zero. So, yes, you do have to wait. Hey, with any luck we'll be bankrupt before then and collecting our fat bailout bonuses.
  • (cs)

    I remember the very moment, as a rookie coder, when I was using VBScript's date libraries and ran into yet another unexpected behavior. I made the crucial mistake of saying "Psh, I can do this better myself" instead of taking the time to understand how the date/time libraries really work.

    I shunned built-in date/time functions and built workarounds for the next 2-3 years. It became second nature to just ignore their existence. Fortunately, I didn't work on a lot of products that used dates except for a timestamp here and there.

    I don't know what caused me to revisit it (either working with a new language or looking at someone else's code) but I soon realized how much time and how many issues I introduced myself too and wasted my life on.

  • Coward (unregistered)

    I see the bug! Sugust has 31 days not 30!:

    else if ( days <= FEBLENGTH+31+31+30+31+30+31+30)
{
   return 8;
}
  • SR (unregistered) in reply to Mark V Shaney
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

    My biggest daylight savings WTF was a calendar app that showed one row too many when the clocks went forward in spring and one too few in autumn.

    The workaround was so ugly I had to code it looking through my fingers.

  • Coward (unregistered) in reply to Coward

    Fixed!~

    Coward:
    I see the bug! August has 31 days not 30!:

    else if ( days <= FEBLENGTH+31+31+30+31+30+31+30)
{
   return 8;
}
  • SR (unregistered) in reply to Coward
    Coward:
    I see the bug! Sugust has 31 days not 30!: 
    else if ( days <= FEBLENGTH+31+31+30+31+30+31+30)
{
   return 8;
}

    Sugust only has 4.5 days ;o)

  • (cs)

    musical interlude Does anybody really know what time it is?

  • Ethan Qix (unregistered) in reply to SR

    Actually, with only 30 days in August, a bug would occur every day during half of the year. This code is obviously not used... or if it is, not finding said bug earlier is TRWTF.

  • silent d (unregistered) in reply to snoofle
    snoofle:
    *musical interlude* Does anybody really know what time it is?

    If anybody really cares, let's hope they don't call the function from this WTF.

  • Kevin (unregistered)

    Apparently:

    August has 30 days September has 31 days October has 30 days November has 31 days December has 30 days

    So during the month transitions of August, October and December, this function would return the wrong value.

    But I bet the real WTF is that FEBLENGTH is a #defined constant that was set once when the code was compiled in a non-leap year.

  • bujo (unregistered) in reply to Coward

    Strange, that dude forgot Sugust all over the place. But maybe the team fixes it soon enough in Deptember.

  • Kevin (unregistered) in reply to Kevin

    Sorry, didn't realise that the actual header was part of the article. I guess my suspicions about FEBLENGTH were unfounded.

  • buji (unregistered) in reply to Kevin
    Sorry, didn't realise that the actual header was part of the article. I guess my suspicions about FEBLENGTH were unfounded.
    We accept your apologies. Just don't do it again, okay?
  • (cs) in reply to Mark V Shaney
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

    In 1986 (roughly) I had to write date/time routines. I finished coding and ran the unit tests, only to see them fail consistently. Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .

  • Ken B (unregistered) in reply to Mark V Shaney
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.
    Sometimes, you need to use in-house libraries because the built-in ones are broken. Other times, people claim that the in-house library is broken when it's not.

    Many years ago, we got bug reports that our IsLeap() function was broken because it said that the year 2000 was a leap year. (We got it right --- 2000 was a leap year --- while many of the "big names" got it wrong, and had to patch it along with their other Y2K fixes.)

  • SCB (unregistered) in reply to dpm
    dpm:
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

    In 1986 (roughly) I had to write date/time routines. I finished coding and ran the unit tests, only to see them fail consistently. Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .
    Probably because 05/12/1984 (5 December) IS a Wednesday.

  • (cs)

    These seem like rather important parts of the story that shouldn't have been left off...

    #define LASTLEAPYEAR 2008 #define LEAPYEARINTERVAL 4 #define SINCELASTLEAPYEAR YEAR-LASTLEAPYEAR #define YEAR time(NULL)/31536000+1970 #define LEAPYEAR ((((YEAR-LASTLEAPYEAR)%LEAPYEARINTERVAL)==0)?true:false)

  • Steve the Cynic (unregistered)

    Let's not forget that in their world, day 22 of each month is formatted in mode 3 as the 22:th... (beats me why the : is there)

    For real fun with ordinals, though, try Welsh, where depending on the number and the grammatical gender of the following noun, the suffix after digits may be -af, -il, -ydd, -edd, -ed, -fed, -eg, or -ain.

  • The_Assimilator (unregistered) in reply to SCB

    It's not "car-crash" code, it's "WTF IS THIS SHIT?" code. I could probably take a dump and the result would make ,ore sense than this pile of garbage.

    SCB:
    dpm:
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

    In 1986 (roughly) I had to write date/time routines. I finished coding and ran the unit tests, only to see them fail consistently. Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .
    Probably because 05/12/1984 (5 December) IS a Wednesday.

    Someone got pwned by date formats...

  • (cs)
    And hopefully, by the time the next February 29 rolls around, someone else will be there to fix it.

    Yes, yet again, complain about something, do NOTHING about it, and leave it to someone else. Which is exactly why code like this exists.

    a) someone weak creates it b) someone with NO BALLS WHATSOEVER finds it c) said person with NO SPINE reports to hilarious internet site, taking about as much time and energy as it would to probably FIX the original problem d) someone like me says "that's why there are so many WTFs, it's because the shit developers are the only ones with spines".

    :(

  • The_Assimilator (unregistered) in reply to The_Assimilator

    *more

    Actually I think this says it all:

    #include <time.h> // Includes base header time.h

    Protip: if you feel the need to comment an #include line, but not the actual contorted and horribly broken logic you've rendered unto your text editor, you may not be a good programmer.

  • Zapp Brannigan (unregistered) in reply to Mr B
    Mr B:
    And hopefully, by the time the next February 29 rolls around, someone else will be there to fix it.

    Yes, yet again, complain about something, do NOTHING about it, and leave it to someone else. Which is exactly why code like this exists.

    a) someone weak creates it b) someone with NO BALLS WHATSOEVER finds it c) said person with NO SPINE reports to hilarious internet site, taking about as much time and energy as it would to probably FIX the original problem d) someone like me says "that's why there are so many WTFs, it's because the shit developers are the only ones with spines".

    :(

    Ah Leeeeerooooy Jennnnnkinnnnnns!

  • (cs) in reply to buja
    buja:
    *puts c++ beard on*

    • no include guards, which is especially great when using so many #defines

    • expects that someone puts a global "using namespace std;" before including time_help.h (or spreads specific using directives like "using std::cout;" etc. around)

    • no "inline" linkage, so multiple source-files #including time_help.h will result in multiple definition errors

    • mixing floating point with integer calculations without proper cast and relying on compiler specific behaviour

    • "#define SECpYEAR 31536000" some lines later "#define YEAR time(NULL)/31536000+1970" --> yay for still using magic numbers --> double yay for for not putting the definition in round braces

    Oh that code is so great. But regarding that it's not even 2^8 lines long, why not just rewrite instead of fixing?

    You're trying too hard. PS it's a code snippet, include guards are boring and thus not included ;)

    ... seriously though, a lack of parentheses around a macro is just BEGGING for trouble. For extra fun, make macros with unbalanced braces, parentheses, and doublequotes in them... and perhaps throw in a return and/or semicolon occasionally.

  • buji (unregistered) in reply to buja
    buja:
    *puts c++ beard on*

    • no include guards, which is especially great when using so many #defines

    • expects that someone puts a global "using namespace std;" before including time_help.h (or spreads specific using directives like "using std::cout;" etc. around)

    • no "inline" linkage, so multiple source-files #including time_help.h will result in multiple definition errors

    • mixing floating point with integer calculations without proper cast and relying on compiler specific behaviour

    • "#define SECpYEAR 31536000" some lines later "#define YEAR time(NULL)/31536000+1970" --> yay for still using magic numbers --> double yay for for not putting the definition in round braces

    Oh that code is so great. But regarding that it's not even 2^8 lines long, why not just rewrite instead of fixing?

    C++ beard on again

    Oh I have forgotten those:

    • C <time.h> instead of C++ <ctime>

    • expects someone to #include <iostream> etc.

    And as for my initial comment about that time_help.h expects someone to put using declarations before #inclusion: This might be a false assumption. It could also that it just expects someone to write code like

    namespace std { #include "time_help.h" }

    and because of that maybe, the author has #included time.h instead of ctime, because basically ctime is time.h inside namespace std.

  • Still Not Tim (unregistered) in reply to The_Assimilator
    The_Assimilator:
    *more

    Actually I think this says it all:

    #include <time.h> // Includes base header time.h

    Protip: if you feel the need to comment an #include line, but not the actual contorted and horribly broken logic you've rendered unto your text editor, you may not be a good programmer.

    I would suggest a comment on an include line indicates that line - among others - was copy-pasted from some form of "beginner's tutorial"...

  • buji (unregistered) in reply to kastein
    kastein:
    You're trying too hard. PS it's a code snippet, include guards are boring and thus not included ;)

    But the full file has been linked over in the initial post.

  • iToad (unregistered)

    If this is a sample of the code, then the application is probably more of a train wreck instead of a car crash.

  • (cs) in reply to Mr B
    Mr B:
    a) someone weak creates it b) someone with NO BALLS WHATSOEVER finds it c) said person with NO SPINE reports to hilarious internet site, taking about as much time and energy as it would to probably FIX the original problem d) someone like me says "that's why there are so many WTFs, it's because the shit developers are the only ones with spines". e) ??? f) Profit!!!!!!!!!111111ONEUNOELEVENTYONE
    FTFY

    /me runs for cover

  • UpNDown (unregistered)

    Cool, uncopyrighted code! So I can take this and use it for my job!

    Just have to fix that August bug and add some parentheses around the define expressions and we're ready to go.

    Thanks, DWTF!

  • (cs) in reply to buja
    buja:
    *puts c++ beard on*

    It's probably C - single line comments with // are no longer C++ only and it's including time.h rather than ctime.

    buja:
    - no include guards, which is especially great when using so many #defines

    The preprocessor in all the compiler suites I'm aware of cache includes and don't parse them twice. Some people would argue that include guards are just noise (personally I do use them, but that may be more out of habit).

    buja:
    - expects that someone puts a global "using namespace std;" before including time_help.h (or spreads specific using directives like "using std::cout;" etc. around)

    Again, this might be C rather than C++.

    buja:
    - no "inline" linkage, so multiple source-files #including time_help.h will result in multiple definition errors

    I'll let my compiler inline for me where it thinks it's suitable. Most attempts to game the optimising passes of a decent compiler lose.

    buja:
    - mixing floating point with integer calculations without proper cast and relying on compiler specific behaviour
    • "#define SECpYEAR 31536000" some lines later "#define YEAR time(NULL)/31536000+1970" --> yay for still using magic numbers --> double yay for for not putting the definition in round braces

    Oh that code is so great. But regarding that it's not even 2^8 lines long, why not just rewrite instead of fixing?

    Those are definite WTFs, and as you say it looks eminently fixable. It's probably Alex fictionalising things as usual - the submitter probably did fix this.

  • (cs) in reply to SR
    SR:
    Coward:
    I see the bug! Sugust has 31 days not 30!: 
    else if ( days <= FEBLENGTH+31+31+30+31+30+31+30)
{
   return 8;
}

    Sugust only has 4.5 days ;o)

    Lousy Smarch weather!

  • chicago fan (unregistered) in reply to snoofle
    snoofle:
    *musical interlude* Does anybody really know what time it is?

    It is 25 or 6 to 4.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    buja:
    *puts c++ beard on*
    It's probably C - single line comments with // are no longer C++ only and it's including time.h rather than ctime.
    time_help.h:
    void printdate_function(int format) { if ( format == 0 ) cout<<YEAR<<"/"<<MONTH<<"/"<<DAYINMONTH; else if ( format == 1 ) </div>
    My! C has changed since I last used it!
  • (cs) in reply to GettinSadda
    GettinSadda:
    java.lang.Chris;:
    buja:
    *puts c++ beard on*
    It's probably C - single line comments with // are no longer C++ only and it's including time.h rather than ctime.
    time_help.h:
    void printdate_function(int format) { if ( format == 0 ) cout<<YEAR<<"/"<<MONTH<<"/"<<DAYINMONTH; else if ( format == 1 ) </div>
    My! C has changed since I last used it!

    Gah. I hadn't clicked on the link, and was going on what was included in the article body. Apologies.

  • Ethan Qix (unregistered) in reply to The_Assimilator
    The_Assimilator:
    SCB:
    dpm:
    Mark V Shaney:
    Most in-house time libraries I've seen were broken. Including the ones I wrote myself.

    A fun one was detecting the numbers of days between two dates by asking the OS-provided library the number of seconds since a fixed date, and dividing the difference by 86400.

    Worked like a charm... until daylight savings kicked in...

    In 1986 (roughly) I had to write date/time routines. I finished coding and ran the unit tests, only to see them fail consistently. Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .
    Probably because 05/12/1984 (5 December) IS a Wednesday.

    Someone got pwned by date formats...

    Heh. MMDDYY dates FTW. Why the hell did someone create this retarded, mixed-up format to begin with ? :p

    dodges tomatoes

  • (cs) in reply to SCB
    SCB:
    dpm:
    Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .
    Probably because 05/12/1984 (5 December) IS a Wednesday.
    That's a coincidence, yes, but the book explicitly said "May 12 1984 is a Wednesday" in their examples of date/time coding.
  • Micah (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    buja:
    *puts c++ beard on*

    It's probably C - single line comments with // are no longer C++ only and it's including time.h rather than ctime.

    You must've missed the call to cout then.... Or I missed when cout was added to C.

  • (cs) in reply to buji
    buji:
    buja:
    *puts c++ beard on*

    • no include guards, which is especially great when using so many #defines

    • expects that someone puts a global "using namespace std;" before including time_help.h (or spreads specific using directives like "using std::cout;" etc. around)

    • no "inline" linkage, so multiple source-files #including time_help.h will result in multiple definition errors

    • mixing floating point with integer calculations without proper cast and relying on compiler specific behaviour

    • "#define SECpYEAR 31536000" some lines later "#define YEAR time(NULL)/31536000+1970" --> yay for still using magic numbers --> double yay for for not putting the definition in round braces

    Oh that code is so great. But regarding that it's not even 2^8 lines long, why not just rewrite instead of fixing?

    C++ beard on again

    Oh I have forgotten those:

    • C <time.h> instead of C++ <ctime>

    • expects someone to #include <iostream> etc.

    And as for my initial comment about that time_help.h expects someone to put using declarations before #inclusion: This might be a false assumption. It could also that it just expects someone to write code like

    namespace std { #include "time_help.h" }

    and because of that maybe, the author has #included time.h instead of ctime, because basically ctime is time.h inside namespace std.

    A few more to add for you:

    • dateformat and YEARSCOPE should be declared extern to avoid multi definition errors during link
    • using magic numbers instead of enumerations
    • outputting to cout instead of taking in a stream to output to
    • using all caps to indicate macro defines AND global variables...sometimes
    • #include <time.h> // Includes base header time.h Yes, I know what this line does. So does every C/C++ developer on the planet. Please don't put a comment telling me what it does.
    • expecting NULL to be defined
    • appending _function to every function name.

    And that is without even considering the actually algorithms in use. Probably plenty more. Ugh, this is indeed a disaster!

  • Yazeran (unregistered) in reply to dpm
    dpm:
    SCB:
    dpm:
    Turned out that the code was fine; my mistake was using the test data in "Inside Macintosh" (at the time, the best source I could find) which had "May 12 1984" as a Wednesday. I still think very bad thoughts about whoever wrote that . . .
    Probably because 05/12/1984 (5 December) IS a Wednesday.
    That's a coincidence, yes, but the book explicitly said "May 12 1984 is a Wednesday" in their examples of date/time coding.
    Well yes, but it may be that the original manuscript said 05/12/84 and the proof-readers/editors changed it to the more user friendly "May 12'th" before publication.... date format WTF indeed!

    Yours Yazeran

    Plan: to go to Mars one day with a hammer

  • (cs) in reply to Man of Steel
    Man of Steel:
    Managertip: The return on investment of fixing the bug now is zero.

    Anything that prevents a future issue and loss of time/money/resources can be seen as a ROI in my book. The bug can be fixed in a couple hours, and would pay dividends as well as avoiding the case where they use "certain" parts of it that worked. They can fix the bug and hopefully make all parts work correctly in less than a day.

  • Green (unregistered) in reply to Grimoire
    Grimoire :
    - expecting NULL to be defined
    NULL is defined in ctime.h
  • (cs) in reply to Green
    Green:
    Grimoire :
    - expecting NULL to be defined
    NULL is defined in ctime.h
    I think you mean time.h, and yes, it appears to be defined there. Never knew that. Thanks.
  • MadtM (unregistered) in reply to Zapp Brannigan

    [quote user="Zapp Brannigan"][quote]Ah Leeeeerooooy Jennnnnkinnnnnns![/quote]

    Thank You! I always speculated on the name of that Design Pattern.

Leave a comment on “A Waste of Time”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article