Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#146 Dates in VTIMEZONEs are interpreted in the wrong timezone

Matthew Hodgson

Date properties in VTIMEZONE components (e.g. DTSTART for an Observance) are expressed as floating datetime properties. RFC5545 section 3.6.5 says:

"DTSTART" in this usage MUST be specified as a date with a local
time value.

ical4j 1.0.3 interprets these floating datetimes in the JVM's default TZ, however - *not* as a UTC timevalue displaced by the TZOFFSETFROM offset, as implied by the RFC and used by the tzurl.org Olson ICS files. As a result, the textual value of the DTSTART property (and others) get mangled by the canonicalisation rules for your JVM's local timezone (e.g. "19810329T020000" when floating in Europe/London gets stored as "19810329T010000"). This then breaks all subsequent observance calculations.

Instead, these datetimes should be considered floating in a pseudo "UTC+TZOFFSETFROM" timezone. However, it's unclear how the current DateTime class allows you to achieve this.


  • Mark Hobson
    Mark Hobson

    This is somewhat coincidental -- I recently posted about the same problem on the forum:

    I was about to raise an issue but I'll use this one if that's okay?

    As the post concludes, I believe the underlying problem is that local DateTimes are parsed using the platform's default timezone rather than the UTC timezone, which is used when no timezone is applicable.

    I'm not sure whether we want to raise a more specific issue for this, but I'll attach a patch for what I think is wrong with DateTime.

  • Mark Hobson
    Mark Hobson

    Hmm, not sure how I can attach a patch. Here it is reproduced from my forum post:

    diff -r 3790aea65bc5 src/main/java/net/fortuna/ical4j/model/DateTime.java
    --- a/src/main/java/net/fortuna/ical4j/model/DateTime.java Fri Feb 03 00:27:46 2012 +1100
    +++ b/src/main/java/net/fortuna/ical4j/model/DateTime.java Fri Feb 10 14:36:23 2012 +0000
    @@ -283,7 +283,7 @@
    throws ParseException {
    // setting the time to 0 since we are going to reset it anyway
    super(0, Dates.PRECISION_SECOND, timezone != null ? timezone
    - : java.util.TimeZone.getDefault());
    + : TimeZones.getDateTimeZone());
    this.time = new Time(getTime(), getFormat().getTimeZone());

    try {

  • Heh - I should have checked the forum first; it is indeed the same issue. Glad I'm not the only one working against it.

    The thing is, though, that the correct behaviour isn't to treat the VTIMEZONE floating dates as UTC - instead they have to be interpreted in the "local timezone" of... the timezone they're defining. Which isn't quite as circular as it sounds, as there's a welldefined TZOFFSETFROM value for the component that says how to interpret "19810329T020000" (in my example, as taken from Europe/Paris) should be interpreted in UTC+1, not UTC. If you parse it as UTC, then you end up with wrong absolute times for the transition in question (in this example it'd claim that the clocks change at 2am UTC, rather than the actual 2am CET (UTC+1)).

    That said, my actual problem was just one of comparing timezones - not calculating the timings of the DST transition, so I did hack my ical4j to interpret the floating values as UTC for now. I'll try to attach my patch for the record - although it's definitely not the correct general-case solution.

  • A dubious patch for interpreting all floating date properties as UTC to work around this bug

  • Mark Hobson
    Mark Hobson

    Ah, I see, that kind of makes sense. I probably didn't appreciate this as my example had TZOFFSETFROM: 0000. Sounds like the proper fix will be less trivial than I imagined.