#169 Bad behaviour with net.fortuna.ical4j.model.Date

Beta (1.0)
open
nobody
None
5
2014-01-24
2014-01-10
Quentin Bérard
No

Hello,

here a very strange behaviour with the ical4j date object :

public class Main {

private static SimpleDateFormat s   = new SimpleDateFormat("yyyy-MM-dd Z");

public static void main(String[] args) {
    // January, 07 2014
    int year = 2014, month = 01, day = 07;
    GregorianCalendar cal = new GregorianCalendar(year, month - 1, day);
    net.fortuna.ical4j.model.Date icalDate = new net.fortuna.ical4j.model.Date(cal.getTime());

    System.out.println("Original date : " + s.format(cal.getTime()));
    System.out.println("New date      : " + s.format(icalDate));

}
}

Output :

Original date : 2014-01-07 +0100
New date      : 2014-01-06 +0100

Why the date is not the same ?

PS : same behaviour with :

net.fortuna.ical4j.model.Date icalDate = new net.fortuna.ical4j.model.Date(cal.getTime().getTime());

Discussion

  • More investigations :

    private static SimpleDateFormat s   = new SimpleDateFormat("yyyy-MM-dd HH-mm-ss Z");
    

    ->

    Original date : 2014-01-07 00-00-00 +0100
    New date      : 2014-01-06 01-00-00 +0100
    

    And the date is modified here : net.fortuna.ical4j.model.Date line 293

    cal.set(Calendar.HOUR_OF_DAY, 0);
    
     
    Last edit: Quentin Bérard 2014-01-13
  • Last info, I am in France so use

    cal.setTimeZone(TimeZone.getTimeZone("GMT+01"));
    

    to repeat the bad behavior

     
  • Ben Fortuna
    Ben Fortuna
    2014-01-13

    Hi Quentin,

    This could possibly be a result of how ical4j calculates the timezone of Date objects by default. In the iCalendar specification a DATE object doesn't really have a timezone associated with it, but in the ical4j implementation it does (as it is based on a java.util.Date object). An unfortunate side effect of this is that a Date object can be affected by daylight savings rules for the associated timezone. So currently ical4j offers two approaches to setting the timezone:

    1. Use UTC time (no DST rules, but depending on how the Date is constructed it may change the displayed value - I suspect this may be happening in your case)

    2. Use local timezone (in rare cases the DST rules may affect the displayed value).

    By default option 1 is used, but you can override this with the following flag in the ical4j.properties file:

    net.fortuna.ical4j.timezone.date.floating=true

    Alternatively you can avoid using the constructor that accepts a java.util.Date object, and instead provide a date string value. This should always display the correct value, however when the local timezone is used any calculations (recurrences, etc.) may still be affect by DST rules.

    That's my theory anyway on what is going wrong here. :)

    regards,
    ben

     
  • Thanks, it's work fine with net.fortuna.ical4j.timezone.date.floating=true .

    So without this option, my opinion is that ical4j is buggy when server time is not GMT.
    Or maybe adding a bit of doc to the Date object, and all methods related with date could do the job

     
    Last edit: Quentin Bérard 2014-01-24