Re: Diary icalendar tests still broken

Stefan Monnier <[email protected]> writes:

>> How then could the validation function (that's what you mean, right?)
>> distinguish between the case where a UTC time (correctly) has no TZID,
>> and the case where a Europe/London offset 0 time is missing a TZID?
>
> You can't and you have to be permissive in your validation?
> What's the expected harm if your validation accepts a case where a UTC
> time has a TZID=3DUTC?
> What should it do anyway with "almost UTC but not quite" like GMT?

FWIW the validation functions we are talking about here are run when
constructing an iCalendar syntax tree in Lisp code for export, not when
parsing data from elsewhere.  The case you describe will *parse* just
fine, but the library shouldn't output such data.  "Be conservative in
what you do, be liberal in what you accept from others", right?

The question we are discussing here is how times should be represented
internally so that we can output them correctly.  The failing tests are
for features of diary export.  They are failing in offset-0 time zones
because the internal representation needs to draw the distinction
between offset-0 and UTC more clearly, which is what the patch does.

>> "TIME is a list (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>> in the style of =E2=80=98decode-time=E2=80=99, so that (encode-time (dec=
ode-time ...)) works.
>> In this list, ZONE can be nil for Emacs local time, t for Universal
>> Time, ..."
>
> Ah, I missed that.  Then I guess it's OK.

Glad to hear it.  Is there anything else that needs to be changed in the pa=
tch?=20

--=20
Best,
Richard