CODEWITHSUNDEEP
javadst
addy
addy

Reputation: 385

Disparity in time across JDK versions

Ran the following code : 

import java.util.Calendar; 
import java.util.Date; 
import java.util.TimeZone; 

public class CalendarTest { 
    public static void main(String args[]) { 
        int[] constants = { Calendar.HOUR, Calendar.MINUTE, Calendar.SECOND, Calendar.MILLISECOND }; 
        Calendar cal1 = Calendar.getInstance(TimeZone.getTimeZone("ART")); 
        cal1.set(Calendar.AM_PM, Calendar.AM); 
        cal1.set(Calendar.DAY_OF_MONTH, 1); 
        cal1.set(Calendar.MONTH, 5); 
        cal1.set(Calendar.YEAR, 2015); 
        for (int i = 0; i < constants.length; ++i){ 
             cal1.set(constants[i], 0); 
        } 
        System.out.println(cal1.getTimeInMillis() + " | " + new Date(cal1.getTimeInMillis())); 
   } 
} 

Output for JDK_1.7.0_76: (time zone database 2014j) 
1433106000000 | Mon Jun 01 02:30:00 IST 2015 

Output for JDK_1.8.0_51: (time zone database 2015d) 
1433109600000 | Mon Jun 01 03:30:00 IST 2015 

Output for JDK_1.8.0_40: (time zone database 2014j) 
1433106000000 | Mon Jun 01 02:30:00 IST 2015

As far as I know Argentina and India do not observe daylight savings as of June 1 2015 and yet I observe difference in time among JDK versions.

Updated : How do you recommend storing time in the database to accommodate such errors ?

Upvotes: 2

Views: 42

Answers (1)

chrylis -cautiouslyoptimistic-
chrylis -cautiouslyoptimistic-

Reputation: 77226

Note the time zone database 2014j. Apparently there was an update to the database in 2015 that reflected a new DST rule.

As far as storing times, that's easy: persisted or transmitted dates should be in UTC or in ISO8601 with zone offset, always, and formatted for display lazily. In SQL, this means UTC.

Upvotes: 1

Related Questions