Monday, October 29, 2012

Few tips on date handling

Handling of Dates have always been an interesting aspect in any programming task irrespective of the environment or language used. When you are developing software in an enterprise environment where multiple disparate systems try to communicate with each other, it becomes even more interesting.

The root cause is generally the lack of standard among the parties. However in an enterprise environment you don't get to establish standards across the board as most of the time you are integrating in to existing systems or standardization simple does not exist. The problems that may occur due to this may seem trivial once you find them, but could be hard to pinpoint when you are dealing with complex integrations.


Some common pitfalls I’ve come across are;

1. Datetimes are either stored or sent without timezone information - Different systems interpret them differently.
E.g : The date 01/01/2012 could be interpreted by 1 system as 01/01/2012 - UTC or another as 01/01/2012 GMT+8 leading to disaster.

2. Sensitivity of the date times. Different systems could interpret a date differently based on how they react to the accuracy level of a date object.
E.g Some could be accurate to the second while another system expects dates to be accurate to the millisecond.

3. Ambiguous display of dates in the user interface - I always prefer to use the format dd-MMM-yyyy (12-Sep-2012) when displaying dates in the UI. This is a far better format than dd-mm-yyyy (12-10-2012) which can easily be misinterpreted to mm/dd/yyyy (10-12-2012).

2. Maintenance of servers to make sure that they are upto date with latest daylight saving patches.
E.g : I’ve seen programs suddenly misbehaving because a certain DST patch is not properly installed in the server they are running. This is especially true in dev and test environments as the SLAs for maintaining them are usually more lenient.

3. Making sure that all integrated servers are synched by the same clock.
Generally this just works, but in an environment where you have different platforms (say unix servers in a primarily windows environment) this can happen.

Best method to solve these issues (at least the ones directly related to software) is not to rely on developers to solve them on a day to day basis. The design of the system should force developers to always do the right thing.

Some of the guidelines that I follow are;

1. Make sure that the data store always have date fields with timezone - Choose the correct data type
2. Have extension methods to specify timezone (I always prefer to use UTC) by default and use them in your outward communicating facades like the DAL layer or web services layer. e.g (.Net)

public static DateTime UtcDate(this DateTime value)
       {
           return
DateTime.SpecifyKind(value, DateTimeKind.Utc);
       }
Another extension to this is to establish standards both within and across layers as to the type of dates that the layer supports. As an example;
- Presentation layer is Local Time always
- Business logic layer works in UTC
- Persistence and integrations works in UTC

3. Use a custom user control with dd-MMM-yyyy format to always render dates to the UI
Post a Comment