Dates, how I love dates!
Dates are great to have as meta data on documents as they allow you to make detailed selections and searches, enable time critical workflows and allow for life cycle management.
But dates also have a dark site to them: International date formats
Those date formats to meta data can be what the different standards for power plugs are to travelers. A nightmare, if not taken into account before embarking.
It always surprises me how many software vendors and websites still not seem to grasp the fact that they need to think about their date formatting when programming forms and views. There still seem to be developers that have no clue that what they consider a normal way of formatting dates isn’t necessarily as logic to someone else.
Oh, is there a difference then? Yes there is!
The most notable difference in date formats is the order in which the different date elements; years (Y), months (M) and dates (D), are portrayed. Either YMD or MDY or DMY depending on where on earth you call home. But not just the order differs, the separator symbol used to differentiate between the elements can differ within those regions as well: ‘/’ or ‘-‘, sometimes even dots ‘.’. And all this can have consequences if not taken into account.
So? what can go wrong?
Misinterpretation of output: If a system displays 1/2/2012….. Are we talking the 1st of February or 2nd of January? Ask any UK person and they will say the 1st of February, ask an American and he will see 2nd of January.
Misinterpretation of input: If a user enters 30/4/2012 into a system that thinks it will get a mm/dd/yyyy (different order) or a dd-mm-yyyy (right order, different separator) it will probably cause that system to throw an error maybe even crash. However, even worse then throwing errors is when the system will accept it as a valid date but in the wrong format, which will effectively happen with all dates before the 12th of each month. It might not throw an error but your date will not be correct.
Consider the implications if that happens on the expiry date of a major contract that should give you an alarm in time to renew…
What to think about when using dates in applications
1. Validation: Server side or client side? How do you pass the date to the back end system? Do you pass the date data as a string or as a date element to the back end and what does the back end system expect? You would be surprised how many applications pass dates as string elements with no additional validation on the client side. So make sure you validate!
2. Dynamic or fixed format: What date format do you use? Do you require a specific date format (e.g. always mm/dd/yyyy) from a user or do you allow dynamic date formatting based on their local preferences (e.g. mm/dd/yyyy to a US user while dd-mm-yyyy to a Dutch user)? I know it’s a lot easier to just specify one date format and require input always to be in that form but that isn’t very user friendly and can cause problems for them so consider what is important before doing it.
3. Local date format source: If you use dynamic formats, what is your base setting, where do you get the users preferred format from? Do you use personal profiles where users can specify it, client settings (if run from a client environment), the browser language or the OS Locale settings? All more or less acceptable but all with their own challenges of scope accessibility and logic.
4. Keep it consistent: If you use dates throughout your system make sure all date elements use the same formatting throughout the application. Nothing is more confusing then dates being shown in a different format in different situations within the same application. And yes, this happens more often then you think unfortunately.
5. Help your users: Make using dates as intuitive as possible to users. Something as simple as inserting a computed text to show the date format behind a date field or having date pickers that will automatically format the date correctly can be of a great help to users.
Don’t leave them guessing what it is you expect. Because if you can get confused by all this, they certainly will…
6. Last but not least… Test: Yes, I know, we all test our stuff thoroughly but this is one area that is often overlooked. So make sure that changing your local settings and inputting wrongly formatted dates is included in the testing. For web apps especially: test with setting your browser language to something different then your OS locale settings. You would be surprised how much trouble that can cause sometimes!
One thought on “Meta data: A Date is a Date is a Date… or is it?”
Store timestamps, not dates. And render them on display.
Comments are closed.