Same Time Next Month?
By Brian Jepson
If you've scheduled something to occur on 12/5/2000, should you expect it to happen on December 5 or May 12? The answer often depends on which country you're in at the time. It also depends on the date format configured in your database. If you're planning to accept orders from customers in other countries, inserting a date with a nonstandard format into your database could cause serious problems. Customers' credit cards could be rejected based on incorrect expiration dates. Orders could be delivered late, or not at all. And bank transactions could go through at unexpected times.
The solution is to standardize your applications and databases on one date format. Date formats can be tricky. Many database systems allow flexible date formats, but not all systems agree on the same one (see
Table 1). With international applications, or even applications that need to work with more than one database system, inconsistencies across date formats can be a major pitfall. What's worse, the supported date formats may not be familiar to your users.
How can you get your applications to accept date data in the format you want? Does every INSERT and UPDATE mean your applications have to convert from the locale-specific date format to a format the database supports? Conversely, will every SELECT statement require that your application convert dates from the native database format to a format recognizable in your application's locale?
If you're using a database system that's flexible with date formats, the answer is no.
