• (nodebb)

    The method name isValidSzulIdo is a nice WTF itself, mixed english and the abbreviation of "születési idő", which means BirthDate in hungarian :)

  • Lawrence Tierney (google)

    Wow. Just wow

  • Sole Purpose of Visit (unregistered)

    "Testing is easy ... we don't need unit tests."

    Indeed. And if only your friendly local Java provider could manage this level of rigorous quality assurance.

  • Derp (unregistered)

    That's the exact point where you beat the senior developer to death with his own shoes.

  • St.Grimes (unregistered)

    Why? The reason why is explained in the comments to the previous article. https://thedailywtf.com/articles/comments/a-case-of-bad-timing/1#comment-488782

  • LCrawford (unregistered)

    "Once it works, it’ll always work, if the code doesn’t change. " At least until the year 2101. Let's all start working on the Y2.101K problems out there!

  • RLB (unregistered)

    TRWTF: "And we know it works, because I copied a lot of this code off StackOverflow".

  • Mike5 (unregistered)

    My eyes! The goggles do nothing!

  • Dave (unregistered) in reply to RLB

    Did they copy the StackOverflow code from the answer or the question?

  • Appalled (unregistered)

    I think I'm batting about 1 out of 20 on code that actually works even the first time from StackOverFlow (and elsewhere for Javascripts/VBScripts/php/vba etc. widgets). The names always suck as well so I get to "refactor" that and add (or fix) some comments. Even so, it's usually worth my time to find a pre-existing wheel and adjust the spokes rather than creating a new one.

  • Yazeran (unregistered)


    A WTF^2

    first rolling you own date manipulation (always a WTF)! And then doing it with regexes al over, don't get me wrong, regexes has their place (I mostly use them for user input validation), but for this... gah

    The only thing even remotely in this direction which I have made was some 10 years ago where I wanted some timestamps formatted a special way and instead of using the language build-in date handling functions i forked out to 'date +%...' using a shell execute (which is also somewhat WTF-y)...


    Plan: To go to Mars one day with a hammer

  • Marc Wilhelm (github)

    "Senior Developer"...

  • akozakie (unregistered)

    Hey, there's nothing wrong with rolling your own date handling lib! ...as long as it's a thin wrapper on an existing one, more suited to your particular use case. In any other case it's a guaranteed WTF.

  • comments.Count.ToString + "th" (unregistered) in reply to balazs

    At least they didn't use Hungarian Notation.

  • my name is missing (unregistered)

    isValidSzulIdo is a special kind of Hungarian notation

  • Adam (unregistered) in reply to Derp

    And bonus, no one could be sure what date or time you did it.

  • I'm not a robot (unregistered) in reply to akozakie

    So how does that existing library get written in the first place?

    (Anyone who answers with a variation of "wrappers all the way down" is hereby kicked in the head.)

  • Milan (unregistered)

    I will not defend this example as it is obviously bad. But... Java date and time handling is trap next to a trap. Single app, single VM is quite ok, but when you start working with multiple server/clients architecture over multiple time zones, it is living hell to get the data correct. Throw in database storage and users with wrong time zones set and you will switch java.util.Date to java.lang.String fast. Utility class is then one step down this road.

  • RichP (unregistered)

    Ah, that old classic rhyme we all learned in CS101: "thirty days hath September, April, June, and 0thmer"

  • And what exactly is this? (unregistered)

    The hell is a 0th month and why does it have a length?

  • Just Another Developer (unregistered) in reply to And what exactly is this?

    My guess is that it's a duff month so that the indexes line up with the month number. 1 for Jan, 2 for Feb etc. Obviously doing monthNumber - 1 was too difficult.

  • Brian (unregistered)

    "It works, so we don't need unit tests." Probably the most facepalm-worthy statement in the whole article. Have you tested every conceivable case (and a few inconceivable ones)? Can you guarantee that some hotshot college kid or HPC won't come along and "fix" the code, with the consequence of breaking whatever other code relies on the particular quirks and bugs of this library? Ignoring unit tests, especially in utility libraries, is a good way to shoot yourself in both feet.

  • MiserableOldGit (unregistered) in reply to And what exactly is this?
    The hell is a 0th month and why does it have a length?

    Maybe he has to handle incomplete dates? like "we only know the year this guy was born in, so store it anyway!"

    I've always found that stuff a PITA when in comes to strong types and standard libraries.

  • Rafa Larios (unregistered)

    I always loved the 0th month.. and 29 days for february works almost always!, and empty dates are valid!..

    Oh my god.. this entry has more WTF's per line of code than anything I've seen in this site for 0th months!

  • Joseph Osako, Jr. (github)

    Standard libraries, how the fuck do they work?

  • That's even more amusing (unregistered) in reply to Rafa Larios

    Looking at the is valid date function 0 will validate as a valid month, as long as it doesn't have more than 31 days.....

  • Rocky (unregistered) in reply to Milan

    I don't understand the problems people have with passing date and times between applications. Just use the ISO 8601 standard. Problem solved.

    And users having their machines set to the wrong TZ has zero impact on how you should handle dates, it's a data validation issue.

    Switching to String is the lazy way out instead of doing it right.

  • Quite (unregistered) in reply to Brian

    I had exactly this argument with one of my "indirect" colleagues, who was very proud of having programmed an IBAN validator (possibly as the very first thing he / she / it ever coded). It was seriously not very good. I pointed out that the way it was coded did not match the specification in Wikipedia, and there were clearly some edge cases for which it looked like it very probably would not work.

    "But it passed the test cases I gave it," was the response, "therefore it must be correct."

    This is the business logic of it:

            IBANNumberValue = IBANNumberValue.replaceAll(" ", "");
            String reformattedCode = "";
            if (IBANNumberValue.length() > 4)
                reformattedCode = IBANNumberValue.substring(4) + IBANNumberValue.substring(0, 4);
                reformattedCode = IBANNumberValue;
            long total = 0;
            for (int i = 0; i < reformattedCode.length(); i++) {
                charValue = Character.getNumericValue(reformattedCode.charAt(i));
                if (charValue < 0 || charValue > 35) {
                    total = 0;
                total = (charValue > 9 ? total * 100 : total * 10) + charValue;
                if (total > MAX) {
                    total = (total % MODULUS);
            total = (total % MODULUS);

    ... read it and weep.

    I just let him get on with it, as it was peripheral to my own working brief. One day I will rewrite it properly and have it available to "save the day" with when a customer panics that their IBAN won't verify.

  • szladkey (unregistered)

    "java.util is a big black box, nobody understands how it works" -- OK, but then why they use java.util.regex.Pattern? Isn't it the same blackbox?

    Second: there is Javadoc which is the specification how it works. Third: there are source code for Java standard library and always was distributed with every JDK. But I agree: to understand how that works one has to read and no one there can read, only write.

    Unit testing is also not that important if you are OK with customers complaining later. Why spend money on tests if users will test for free?

  • TheCPUWizard (unregistered)

    And there is the door.....don't bother coming back.

  • Simon (unregistered) in reply to Rocky

    Well, consider... I have a java.util.Date object on the server, which per the Java specs, is a specific instant in time, complete with timezone information. Now you pass it across the wire to a client in a different timezone... one hour west. Now it's the same instant in time, but interpreted in a different timezone... so far, so good.

    But here's the kicker – it's very likely that you didn't want your date to be an instant in time... you just wanted a simple date, so you throw away the time component when formatting it for display. But if the date that came from the server had a time component earlier than 1am (often 00:00:00.0, because they explicitly didn't want a time component), the date component (after an unwanted timezone adjustment) is now one day earlier than intended. And now the users are complaining that the screen is displaying wrong...

    This is how fucked up the Java date APIs were, prior to Java 8 – there was no way of representing any form of date other than a full date/time/timezone... you either used the Date class and tried to work around the limitations, used a third-party date library like Joda (which didn't exist early on), or you wrote your own. So naturally, most developers did the latter, and unsurprisingly, a lot of them did it badly.

  • Viper (unregistered)

    I would go home that day and look for another job.

  • MCalus (unregistered) in reply to balazs

    Well, does it count as hungarian notation then? :D

  • Tim Anderson (google)

    "The senior developer responsible explained:"

    With an explanation like that, you can't claim to be senior, a developer or responsible.

  • Joseph Osako, Jr. (github) in reply to Tim Anderson

    Sure he can. He can blame it on a 'senior moment'.

  • siciac (unregistered)

    And we know it works, because I copied a lot of this code off CrackOverflow.


  • Caiwan (unregistered) in reply to balazs

    Well, the rest of the code base has the same half-Hungarian-English naming convention.

  • doubting_poster (unregistered) in reply to Simon

    Nice WTF in your example there. The failure is in throwing away hour information and expecting things to magically not break... What you do in that instance is NOT throw away the exact time data but keep it, as it is relevant. Then you send that data over, and truncate to days in display code only -> no more issues.

  • nikolay (unregistered) in reply to Dave

    asking the real question here ...

  • Ed (unregistered) in reply to Milan

    Java 1.8 makes doing Date and Time work MUCH easier now. I agree with your comment but if you are on Java 1.8 use the new API and ditch this nasty piece of code. My 2 cents.

  • Zenith (unregistered)

    Having read through alot of the WinForms code in .NET framework 4, I can't help but agree with distrusting the built-in or 3rd party libraries.

  • timetraveler1902 (unregistered)

    2101k problems, if only we get that far... I mean if there is a future past 2038 :-) (for those unfamiliar: https://en.wikipedia.org/wiki/Year_2038_problem )

  • Caiwan (github)

    Up until this point I haven't even noticed that, there's two January ("0th" (sic!)) in the lookup table.

  • Barf4Eva (unregistered) in reply to Milan

    It really is... People often over-simplify this...

    Blindly taking the windows files of timezone information as gospel will burn you to hell if you require historically accurate timezone data.

    But one has to remember it always seems simple(r) until you begin to dig in to taking all of these bits of information in to account... And next thing you know, you are pulling down shape files, parsing city lists, longitudes, and latitudes, doing lookups to get the right location to pass to tzdb (in NodaTime in my case) to get the right timezone... and on and on... ;)

    Luckily, plenty of kind souls have already done alot of the legwork for us... As some have mentioned on here about stackOverflow for code that doesn't always work right, it is ALWAYS on us to do the proper research to find the right answers... Think of a time before Stackoverflow and all the wonderful online help that exists now...

    Oh yes, I lived during that time... :(

    I like this current decade of digging and learning MUCH better. :)


  • (nodebb) in reply to Barf4Eva

    Blindly taking the windows files of timezone information as gospel will burn you to hell if you require historically accurate timezone data.

    I believe Windows 8 finally joined the rest of the rest of the civilised world and started using the Olson (IANA) database. Unfortunately I can't check whether completely, because we still have Windows 7 at $work (and I don't use Windows at home at all). But at least the WinRT API returns the IANA identifiers.

    For older Windows, CLDR has a table to guess the correct timezone from the Windows timezone and region.

    And in a sense, the hack it uses for Unix is worse. Because while Unix does use the Olson database, the /etc/localtime might be a copy of the data file and the data file does not contain its identifier. So ICU walks the database and compares the file to each one there… Talk of well designed API.

Leave a comment on “We Know How This Works”

Log In or post as a guest

Replying to comment #:

« Return to Article