Re: Diary icalendar tests still broken

> Right, and remembering the timezone is exactly the source of the test
> failures in question here.
>
> iCalendar properties record the timezone in a "TZID" parameter separate
> from the time value (which is parsed as a decoded time).  The standard
> disallows this parameter when the time value is in UTC, so there is a
> validation function in the library that verifies that when the TZID
> parameter is present, the associated time value is not a UTC time.
> The tests were failing on systems in these time zones because this validation
> function saw a 0 offset in a property with a TZID like "Europe/London",
> and thought, "That's a UTC time with a TZID, that's not allowed," and
> signaled a validation error.

But isn't that simply a failure of the test rather than the main code
(i.e the test shouldn't take "offset == 0" as being a sign that the
timezone is UTC)?

What I'm getting at is that I'm not sure this iCalendar standard's weird
quirk (about TZID not being allowed to be UTC) is a good justification
to change the definition of `decoded-time` to allow the `zone` field to
be `t`.


=== Stefan