Re: Diary icalendar tests still broken

Stefan Monnier <[email protected]> writes:

>> 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 valid=
ation
>> 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 =3D=3D 0" as being a sign that the
> timezone is UTC)?

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?

I guess I could store "UTC" as a TZID for UTC times in the parser and
handle it specially in the printer, but I'm pretty sure that would be a
bigger and finickier change to make than the one I'm proposing here,
because it would mean that all places in the code where UTC is handled
specially would need access to that TZID, instead of just looking at the
zone slot of a decoded time.

> 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`.

To be clear, this isn't changing the definition of a decoded time to
allow the zone to be `t'; AFAIU that is *already* explicitly allowed.
Both `decode-time' and `encode-time' explicitly use `t' to mean UTC
time.  E.g. the docstring of `encode-time' says:

"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 (decode=
-time ...)) works.
In this list, ZONE can be nil for Emacs local time, t for Universal
Time, ..."

Indeed, once I realized this, I assumed that `t' was allowed in ZONE
precisely to distinguish UTC from the mere offset 0 case, and felt dumb
for having initially overlooked this when writing the parser.

So I think all I'm changing here is *which subset* of decoded times are
used to represent UTC times in the library, not what the library or the
rest of Emacs considers to be a decoded time.

(It's true that `decode-time' will put a 0, not `t', in the zone field
when you decode a time into universal time, but I'm guessing that's just
because that's how it comes back from C, where `t' is not a thing.)

--=20
Best,
Richard