Wednesday, July 6, 2011

Java EST to DayLight Saving conversion

We are gifted. We live in the part of the world, where Sun rises on almost the same time on the each day of the year. So we don't need to worry about the "Day Light saving time" conversions during any Software development. But this cannot be prevented, when you have to develop a system for clients, who are in such regions.

Yesterday I had to work on bug, which is giving some confusing results during the DayLightTime saving peirod (march - november). I had different web users located in different part of the world. Their respective TimeZone was attached to their UserProfile. This UserProfile TimeZone will be used to convert the Date/Time value, shown within the Web UI system. It converted the Time properly when a "PST" timezone user logged in. But when "EST" timezone user logged in, system showed the time without the DayLightTime saving conversion. So I wrote a small test method to verify it. Here I have assumed that my source Date/Time is stored in the Asia/Colombo timezone.



private static void testDayLightSupport(String tz, int month) {

DateFormat dateFormat = new SimpleDateFormat("yyyy:MM:dd HH:mm:ss z");
dateFormat.setTimeZone(TimeZone.getTimeZone(tz));
System.out.println("==========Month =" + (month + 1) + "==========================");

Calendar cale = Calendar.getInstance();
cale.set(2011, month, 12, 14, 34);
cale.setTimeZone(TimeZone.getTimeZone("Asia/Colombo"));
System.out.println(dateFormat.format(cale.getTime()));
}



I passed the "PST" as the TZ string and tried it.


testDayLightSupport("PST", 1); // February
testDayLightSupport("PST", 3); // April
testDayLightSupport("PST", 6); // July
testDayLightSupport("PST", 12); // December


Results were :

==========Month =2==========================
2011:02:12 01:04:33 PST
==========Month =4==========================
2011:04:12 02:04:33 PDT
==========Month =7==========================
2011:07:12 02:04:33 PDT
==========Month =13==========================
2012:01:12 01:04:33 PST


Results were quite satifying as there is a one hour difference in the conversion and timezone was specified as PDT. But I passed the "EST".


testDayLightSupport("EST", 1); // February
testDayLightSupport("EST", 3); // April
testDayLightSupport("EST", 6); // July
testDayLightSupport("EST", 12); // December


Results were :

==========Month =2==========================
2011:02:12 04:04:58 EST
==========Month =4==========================
2011:04:12 04:04:58 EST
==========Month =7==========================
2011:07:12 04:04:58 EST
==========Month =13==========================
2012:01:12 04:04:58 EST



It is terrible. There is no DayLightSaving conversion. I was googling for any similar bug reports, but I found a Java alert on the TimeZone.

Java TimeZone alert

In that alert, they requested to use the long values as timezones, such as "US/Eastern". These 3 letter TimeZone values were declared to be deprecated as they were ambiguous. After the introduction of the Olson's (Java's TZ data provider) new standard, some of the 3 letter timezone values were not continued with the support. When I tried the long values time conversions happened as expected :).


testDayLightSupport("US/Eastern", 1); // February
testDayLightSupport("US/Eastern", 3); // April
testDayLightSupport("US/Eastern", 6); // July
testDayLightSupport("US/Eastern", 12); // December

Results were :

==========Month =2==========================
2011:02:12 04:04:43 EST
==========Month =4==========================
2011:04:12 05:04:43 EDT
==========Month =7==========================
2011:07:12 05:04:43 EDT
==========Month =13==========================
2012:01:12 04:04:43 EST