Ok I’ll rant off about one of my pet peeves with the Java programming language. I use the language on a daily basis and generally love it. It’s grown over time, and like anything that you build on, after a while you realize there are parts that aren’t so great. I should know, the code base for AA.com is much the same way.
Sun initially had the Date object to store dates like June 1st, 2006 2:06 PM CST. Then they realized, well, not such a great implementation. So, voila! along came Calendar. Much more robust and feature rich (and also more resource intensive, but what the heck, just add another processor in there). The problem was everything already used Date. So, you were given the ability to get a Date from a Calendar but told repeatedly everywhere by deprecated methods to NEVER USE DATE. You could almost read the wink in it, like, “Don’t use this, but well, everything uses it, so keep using it. Just don’t use it.”
The problem I’ve run into on years of working on websites (which run 24/7 and cross all time zones) are time zone issues. My biggest pet peeve is getting a Date from a Calendar in a different time zone. So I have 9 AM Eastern time and I get the Date, well, Date isn’t nearly as sophisticated about time zones, so it goes and gets the equivalent of this time construct based on the system’s time zone: central. So suddenly I have 8 AM Central! The most elegant solution I’ve found is virtually in every code base I’ve worked on I write a custom set of Date utility methods which force a Calendar in one time zone into another Calendar that has the same date/time values but a different time zone. So 9 AM Eastern/8 AM Central becomes 9 AM Central, then it comes out right in Date format.
There, I’ve vented. And if you’re not a complete geek you didn’t get this far. ![]()