Created and non-UTC data

[douglm]

The code below allows invalid data to be parsed. CREATED should always be UTC.

/** * @param aDate a date */ public Created(final DateTime aDate) { super(CREATED, new Factory()); // time must be in UTC.. aDate.setUtc(true); setDate(aDate); }

It would probably have been better if setting the date to UTC were controlled by the isLenient() setting.

I realize it would be a non backward compatible change but perhaps we can have a strict mode.

I'd like to see ical4j useful as a validator tool and the above code prevents testing for full adherence to the standards.

[benfortuna]

Hi Mike,

So if the concern is for validation of existing iCalendar data then I assume this relates to parsing valid date-time strings. I'd like to approach this in a similar way to how we parse date strings in iCal4j v4.

In v4 as we are using the java.time implementation for date support we allow any java.time.Temporal instance to be associated with a date/time-based property. For UTC-based properties (such as CREATED) we try to enforce use of java.time.Instant via generics, however parsing a string value will still allow non-UTC values (e.g. a floating date-time value).

The philosophy we try to maintain in iCal4j is one of lenient parsing, but strict output/formatting. So we should never allow output of invalid data, even when it was originally parsed from invalid source data. So for iCal4j v4 we ensure that UTC-based properties will always output UTC-formatted values, even when parsed from non-UTC date-time strings.

Looking at the code for iCal4j v3 I think it may allow for invalid UTC-based properties to be both parsed and output, which I agree should be fixed. I will work on some tests to validate and fix this.

Regarding iCal4j as a validation tool, I see validation as a separate function that exists independently of parsing. For example, we can allow lenient parsing of non-UTC date strings, but strict validation of the resulting object model would flag this as an error. This also allows us to generate a complete list of validation errors that would otherwise be truncated if the parser was to exit prematurely.

Right now I think the validation framework probably also needs some attention to provide that strict adherence to the specifications.