TZID of DTSTART completely ignored when VALUE=DATE about ical4j

[arnaudq]

I dont know who generated this file but in general, having a DTSTART with VALUE=DATE and a TZID, while not illegal, does not make much sense.

See http://tools.ietf.org/html/rfc5545#section-3.2.29

<<
The "TZID" property parameter MUST NOT be applied to DATE
properties and DATE-TIME or TIME properties whose time values are
specified in UTC.

[benfortuna]

Further to what Arnaud said, ideally in ical4j a Date property wouldn't even have a timezone, but due to the limitations of the implementation we set it to UTC by default. Eventually if we can implement the new date/time api (jsr-310) this can hopefully be fixed.

In the meantime though, there is a workaround that may suit you, which is to override the default behaviour and use the local timezone for Date properties. You can enable this by adding the following flag to your ical4j.properties file:

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

[solomax]

Actually there is implementation of JSR-310: http://www.threeten.org/
But it is for Java7 .... (which is almost at the EOL)

[benfortuna]

Yes we have a branch dedicated to integrating the java 7 backport here:

https://github.com/ical4j/ical4j/tree/jsr-310

It may be quite a challenge, but time-willing we'll make some progress on that soon. Feel free to fork and contribute if you are able.

[solomax]

Will try

[atnak]

See http://tools.ietf.org/html/rfc5545#section-3.2.29

Thanks for that, extremely informative.

Further to what Arnaud said, ideally in ical4j a Date property wouldn't even have a timezone, but due to the limitations of the implementation we set it to UTC by default. Eventually if we can implement the new date/time api (jsr-310) this can hopefully be fixed.

Thanks for the insight. I'm now more confident about converting Period.getStart() into a LocalDate.

[jeff303]

We are experiencing this problem as well, but in our case, the DTSTART string is generated by ical4j itself. Working on producing a test case now.

[NoSubstitute]

I dont know who generated this file but in general, having a DTSTART with VALUE=DATE and a TZID, while not illegal, does not make much sense.

See http://tools.ietf.org/html/rfc5545#section-3.2.29

<<
The "TZID" property parameter MUST NOT be applied to DATE
properties and DATE-TIME or TIME properties whose time values are
specified in UTC.

I can't find that section in the RFC.

[NoSubstitute]

Oh, maybe there was a typo in the URL and you really meant this one?
https://tools.ietf.org/html/rfc5545#section-3.2.19