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.

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

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.

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.

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

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

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.

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

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.

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.

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

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.