Simple Features Thoughts about simple features in software development

27Nov/102

Java Dates – Is long a good idea for handling dates?

Answer goes: yes, most of the times, but...

12Nov/090

Time, text and money

A couple weeks ago I was about to deliver a new AVL (Automatic Vehicle Location) communications system. Then we realized that on that weekend, Mexico would finish its daylight saving time: the UTC -5 hour difference would then be the regular UTC -6 hour difference (CST). In our company we established a standard to set the time change coherently through the whole system according to the national settings. But now our system was reporting a -4 difference.

WTF?... How the hell did it go from a -5 returning to a regular -6 to an out of the question -4 and, making it more complex... 5 hours before the time change occurs?

That is the kind of features that can turn a developer into a complete mess in no time... that was the moment my friend Carlos and I remembered one of the most important things in computing: after 60 years of innovation, new technologies, outstanding achievements in science, moon landings, etc., there hasn't been a definitive approach for three primary subjects:

  1. Currency,
  2. text,
  3. and time

Currency, by itself is a data type. Currency can not be represented neither by a float nor a double type. The problem with currency is not how we make simple arithmetics with the Currency class (which verbosity in itself would make us want a career change), but all of the complexity in stating amounts of money when the system is not prepared for exchanges... it's a definitive system killer.

The problem with text is all about charsets. Today I was watching a webcast where one of the oh-my-god! features in text processing for Silverlight 4 was the capability for mixing charsets in the same document. In one paragraph we were watching UTF-8 mixed with some other unicode text. Finally, a text document had a feature only possible using ink over paper and it only took sixty years of technology and research.

With the use of highly verbosed formats (I'm thinking of you, XML) the storage and deployment of information is not an easy task when it comes the time to choose the formats. The first time I used XML I just decided to copy/paste the header I most commonly found on the examples and it always said "UTF-8"; using UTF-8 in spanish language is just slicing the dictionary in half. After some attempts I started using ISO-8859-1 with all of the capabilities it gave me to use the whole of the spanish dictionary but, did I make the right design decision?

Time is a full science. Timezones are a real P.I.T.A.: hour, mid-hour and even weird quarter hour differences (see Nepal here and here and the Chatham Islands here) between timezones are just insane. And there are many things to answer with time:

  1. At what time did X happen? user local time? server local time? and what if my application is distributed?
  2. At what time will happen X?
  3. If timezone changes (mobile devices), is my device aware?
  4. If I'm using Linux and then my application goes to Windows, will the time still be coherent?
  5. and questions may go on and on...

And calendars... has anyone worked with calendars without the need of beeing buried alive? There are no correlation between all of the calendars. For example, lets see two facts of the jewish calendar: years 2009 - 2010 are the 5770th of their time and, the year has 354 days (or 353 or 355) divided in 12 lunar months, filling the remaining days with a leap month periodically.

The major problem about these three things we are talking about: most of the questions arise once it has reached surface as a bug.

A regular company-wide internal application would have to be aware of a these problems. Regularly, the developer would only use the first approach the language and the IDE gives you when you have to deliver a new product. But solving it in a simple out-of-the-box manner will become a decision you will inherit all over your steps (and others´) in the company, and the decision you will ALWAYS regret of.

These three subjects are the reason of existance of this blog. By reviewing those subjects we can realize that there are many simple features all over programming that affect the overall behaviour of a system that are not well addressed for beginners, and that the advanced programmers sometimes just give general advices but not straight answers. Those are not necessarily the only subjects, but we will come back to those frecuently.

In rough terms, that was what happened with our 4 hour difference: I didn't take care of the language behavior when implementing the company's standard. In details, it will be analyzed and fixed next week.