This past week I had a new laptop shipped to me and, like anyone awaiting an expensive new toy, I tracked the package every step of the way. The morning after the laptop left China, I checked the tracking log which looked much like the above image. Unless my laptop somehow made its way from Suzhou, across the Pacific to Anchorage and then back across to Shanghai in just over six hours, the tracking is incorrect.

It’s easy to see where the shipping company went wrong with their package tracking web application. They fell victim to one of the classic blunders of date manipulation: forgetting to include the timezone. If FedEx, the company which “Runs on Time” can make this mistake, then so can you.

If your application deals with dates and times, you should remember the following, among other things:

• If your application stores dates, either include the matching timezone or store all dates based on some fixed timezone, such as GMT or UTC. This way you can easily see how much time has passed between dates, regardless of timezone.
• If your application stores dates and/or times, be sure to include the full date even if you think you will not need it. It is a lot easier to include support for dates and/or times in your code later on than populating them in existing data. This should go without saying, but include every portion of the date that you can. A few years back I was integrating with a client which did not include the year in their stored dates, and it made their application confusing not to mention hampered our integration.
• If your application displays dates, make sure that it does so in a consistent and possibly configurable manner. Confusing your users with several different formats, none of which they can control, does not lead to proper usability. Doing so will also hamper any integration efforts which may occur in the future. I once integrated with an application which used no less than six different date formats in its output. Needless to say, the integration did not go well.