bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
The attached patch contains a fix for what looks like a clerical error
in icalendar--decode-isoduration(), test case: P1DT2H.

But the real point of this post is to propose a few improvements to
handling timezones.

I use icalendar.el as a library for dealing with raw VCALENDAR data.
Also, I'm on Windows where the OS makes Emacs' timezone handling a
bit tricky.  Meaning that, unless precautions are taken, datetime
conversions by icalendar.el sometimes are incorrect, in particular
around DST transitions.

Changes in the patch:

 - add an optional argument to icalendar--decode-isodatetime() which
   is passed to decode-time().

   So, both encode-time() and decode-time() get to have their
   respective timezones which makes datetime conversions predictable.
   I know, I could do a (setenv "TZ" (icalendar--convert-tz-offset
   ...))  before I call icalendar--decode-isodatetime() but that +
   restoring the environment variable afterwards looks clumsy.

 - handle RDATE in icalendar--convert-tz-offset() in a rudimentary
   fashion.

   RDATE handling is required for those VTIMEZONEs that do not specify
   RRULE, otherwise there will be no datetime conversions at all.

 - identify the latest oberservance for DAYLIGHT and STANDARD
   specifications within one VTIMEZONE, again supporting RDATE.

   As is, icalendar.el handles multiple such specifications
   indiscriminately, resulting in conversions that may be relative to
   a date centuries in the past.

   The relevance of this change is this: when a VCALENDAR does not
   contain a VTIMEZONE section or e.g. the popular nonstandard
   X-WR-TIMEZONE property, my application goes and fetches one from a
   tzdata database such as tzurl.org.  Standard tzurl.org responses
   contain lots of historical records.  Yes, tzurl.org also returns
   "Outlook-style" VTIMEZONEs which icalendar.el is quite happy with
   but that doesn't help me with complex VTIMEZONEs contained in
   incoming VCALENDARs.


The patch is not a --git diff.  Is that tolerable at all?

Best regards

Thomas



icalendar.el.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
Thanks for the patch.  I'll have a look.

Ulf



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
In reply to this post by Thomas Plass
Thomas,

the patch looks good so far.  Could you please provide some testcases so
that I can add some unit tests?

Best,
ulf



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
[specific Emacs behaviour/bug question at end, list subscribers please read on]

Ulf Jasper wrote at 18:17 on February 15, 2019:
: the patch looks good so far.  Could you please provide some testcases

thanks.  A set of iCalendar files is in the attached archive
along with a README and a slightly cleaner version of the patch.
However, for unit testing, you'd need to not only consider the
data but the OS, too.  What follows is not only meant as a reply
to your request but is also a question for the Emacs maintainers.

The date-time that prompted me to look at this in detail is Sat,
Nov 3 2018 20:15 Europe/Berlin local time, the OS is Windows (7).
I made tests with two pre-built binaries, the official GNU 26.1:

(emacs-version)
"GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30"

and an older "SourceForge" 25.3 build.

I don't know what makes Sat, Nov 3 2018 (and the weekdays preceding
it) so peculiar, but my hunch is its proximity to the DST transition
that occured on the Sunday six days earlier, the "fifth week" of Oct.

The decode/encode combo in the forms below is essentially the
guts of icalendar--decode-isodatetime(), old and patched.  The
zone rule for Europe/Berlin is the current standard one, also
computed by icalendar--convert-tz-offset().

The point of these examples is to see how time zone rules
missing/supplied/in environment affect date-time conversions.

Here's code for a same-zone scenario, note the two TZ setenv()s:

(let ((Europe/Berlin "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00"))
  ;; force Windows behaviour, usually no TZ set
  (setenv "TZ")                  
  (print (decode-time (encode-time 0 15 20 3 11 2018                            )))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin)              ))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin) Europe/Berlin))
  ;; force Unixoid/POSIX? behaviour
  (setenv "TZ" Europe/Berlin)
  (print (decode-time (encode-time 0 15 20 3 11 2018                            )))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin)              ))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin) Europe/Berlin))
  nil)


Official Windows-26.1 evals to (comments by me):

(0 15 20 3 11 2018 6 nil 3600)          ; correct, no-brainer

(0 15 19 3 11 2018 6 nil 3600)          ; wrong: 19:15?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!


SourceForge 25.3 performs slightly better:

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 19 3 11 2018 6 nil 3600)          ; wrong: 19:15?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 20 3 11 2018 6 nil 3600)          ; correct


Never mind the DST weirdness, I can live with this behaviour as
producing the desired 20:15 is possible in a predictable fashion.

But it get's even weirder.

Consider the following different-zone conversion.
America/Creston is UTC-7, adding UTC+1 for Europe/Berlin makes an
8 hour difference.  So, Berlin 20:15 is Creston 12:15, see also
https://www.timeanddate.com/worldclock/converter.html?iso=20181103T191500&p1=37&p2=2274

Let's check:

(let ((Europe/Berlin "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")
      (America/Creston "STD+07:00"))
  ;; force Windows behaviour
  (setenv "TZ")                  
  (print (decode-time (encode-time 0 15 12 3 11 2018)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston) Europe/Berlin))
  ;; force Unixoid/POSIX? behaviour
  (setenv "TZ" Europe/Berlin)
  (print (decode-time (encode-time 0 15 12 3 11 2018)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston) Europe/Berlin))
  nil)


Eval says (Official Windows-26.1):

(0 15 12 3 11 2018 6 nil 3600)  ; correct (no conversion possible)

(0 15 20 3 11 2018 6 nil 3600)  ; correct 20:15 with "their-zone" conversion only

(0 15 21 3 11 2018 6 t 7200)    ; wrong: 21:15 with "their zone" + "my zone" conversion

(0 15 12 3 11 2018 6 nil 3600)  ; correct (TZ in env applicable for decoding only)

(0 15 21 3 11 2018 6 t 7200)    ; wrong time 21:15 + wrong DST=on

(0 15 21 3 11 2018 6 t 7200)    ; wrong time 21:15 + wrong DST=on


SourceForge 25.3 is slightly different:

(0 15 12 3 11 2018 6 t 7200)

(0 15 20 3 11 2018 6 nil 3600)

(0 15 21 3 11 2018 6 t 7200)

(0 15 12 3 11 2018 6 nil 3600)

(0 15 21 3 11 2018 6 t 7200)

(0 15 21 3 11 2018 6 t 7200)


Things are fine again for dates following (Nov 4 etc.), ie.
when October's "fifth week" comes to an end.

If I remember correctly, Arch Linux pre-built 26.1 is always correct.

So, getting the desired 20:15 is dependent on - what?  Is it possible
to drive decode-time/encode-time to always convert between time zones
correctly and if so, how?  Is this a bug in Emacs or am I just
uninformed?

Thomas


icalendar019-patch+testcases.zip (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Eli Zaretskii
> Date: Mon, 18 Feb 2019 10:36:29 +0100
> From: [hidden email] (Thomas Plass)
> Cc: [hidden email]
>
> I don't know what makes Sat, Nov 3 2018 (and the weekdays preceding
> it) so peculiar, but my hunch is its proximity to the DST transition
> that occured on the Sunday six days earlier, the "fifth week" of Oct.
>
> The decode/encode combo in the forms below is essentially the
> guts of icalendar--decode-isodatetime(), old and patched.  The
> zone rule for Europe/Berlin is the current standard one, also
> computed by icalendar--convert-tz-offset().
>
> The point of these examples is to see how time zone rules
> missing/supplied/in environment affect date-time conversions.
>
> Here's code for a same-zone scenario, note the two TZ setenv()s:
>
> (let ((Europe/Berlin "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00"))

You cannot expect MS-Windows to support Posix DST rules such as above
in the C runtime functions like mktime, localtime, etc.  Windows
support for DST rules in C runtime is very rudimentary, and is limited
to the likes of EST-5DST, without any specification of when the DST
transitions happen (the transition dates are hard-coded in the Windows
C runtime).

I think this factoid goes a long way towards explaining why you get
wrong results for the timezone offset around the DST transition date.

To make myself clear: modern Windows systems do have database of DST
transition rules, and they do apply these rules both for setting the
system clock and in APIs such as GetTimeZoneInformation.  But the
rules are not in Posix format (although the information is of course
equivalent), and these capabilities are not propagated to C runtime
functions which Emacs uses.



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
Eli Zaretskii wrote at 17:59 on February 18, 2019:
: these capabilities are not propagated to C runtime
: functions which Emacs uses.

I take it then, Windows pre-built users have no way to work around
this in Elisp?

What about the C source?  Is there any way for a total C-dummy like me
to tweak/hard wire a rule for my local zone into the source?  Could
you point me at the file(s)/place(s) in the Git that I'd need to look
at?

It'll be daunting to do this on Windows.  The last time I built an
emacs must have been jwz's lemacs under SunOS back in '93...

Thomas



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Eli Zaretskii
> Date: Mon, 18 Feb 2019 20:15:19 +0100
> From: [hidden email] (Thomas Plass)
> Cc: [hidden email]
>
> Eli Zaretskii wrote at 17:59 on February 18, 2019:
> : these capabilities are not propagated to C runtime
> : functions which Emacs uses.
>
> I take it then, Windows pre-built users have no way to work around
> this in Elisp?

Not in Lisp, no.

> What about the C source?  Is there any way for a total C-dummy like me
> to tweak/hard wire a rule for my local zone into the source?  Could
> you point me at the file(s)/place(s) in the Git that I'd need to look
> at?

I don't understand what kind of C-level change do you have in mind.
AFAIU, any change to support this stuff would involve writing (or
importing from a free source) a parser for such DST rules, and then
using APIs like SetDynamicTimeZoneInformation to make the parsed rule
in effect.  It would probably also mean replacing localtime and its
ilk with versions that actually access the DST data set by the above
APIs.  Is that what you had in mind?



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass

Eli Zaretskii wrote at 21:30 on February 18, 2019:
:
: I don't understand what kind of C-level change do you have in mind.

To be frank, I have no idea whatsoever.  If this is something that
hasn't bothered any maintainer enough to fix it, then it's probably no
use for a non-C+non-Windows-API guy like me to try.

All I could do is to lobby?



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Eli Zaretskii
> Date: Mon, 18 Feb 2019 21:03:15 +0100
> From: [hidden email] (Thomas Plass)
> Cc: [hidden email]
>
> All I could do is to lobby?

You could also file a wishlist bug report.  Maybe someone will be
interested enough to do something like that, who knows.



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
In reply to this post by Ulf Jasper
It seems that I lost track of this issue.  Sorry.

Am 10.08.2020 um 13:48 (+0200) schrieb Lars Ingebrigtsen:

> As far as I understand it, the patch itself is good and fixes a real
> problem in icalendar date parsing?

IIRC the patch looked good insofar as it appeared to address only the
observed problem and to be properly documented and formatted although I
was not able to reproduce the problem.

> But then the thread turned towards questions about daylight savings
> time handling in Windows, and the patch itself wasn't applied?

Right, the patch was not applied.

Eli pointed out that the root cause lies in the dst handling in
ms-windows (and not in newsticker). That makes the patch more of a
work-around than a fix.

I admit that I am not very much inclined to check and apply the patch as
I do not have a ms-windows box to run tests on.

Eli, what do you think?





Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Eli Zaretskii
> From: Ulf Jasper <[hidden email]>
> Cc: [hidden email] (Thomas Plass),  [hidden email]
> Date: Mon, 10 Aug 2020 18:08:34 +0200
>
> IIRC the patch looked good insofar as it appeared to address only the
> observed problem and to be properly documented and formatted although I
> was not able to reproduce the problem.
>
> > But then the thread turned towards questions about daylight savings
> > time handling in Windows, and the patch itself wasn't applied?
>
> Right, the patch was not applied.
>
> Eli pointed out that the root cause lies in the dst handling in
> ms-windows (and not in newsticker). That makes the patch more of a
> work-around than a fix.
>
> I admit that I am not very much inclined to check and apply the patch as
> I do not have a ms-windows box to run tests on.
>
> Eli, what do you think?

My comments were not about the patch (which I admit I don't really
understand, as I don't use icalendar), but about the attempts to see
what happens with time under different TZ settings.

As for the patch, I've looked at it again now, and I don't think it's
specific to MS-Windows, is it?  If so, and if you think it's good,
feel free to install.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
Eli Zaretskii wrote at 19:45 on August 10, 2020:
:
: As for the patch, I've looked at it again now, and I don't think it's
: specific to MS-Windows, is it?

Exactly, the patch has nothing to do with MS-Windows' DST handling
(though incidentally, it was developed while dealing with that issue).

It fixes general issues with icalendar.el's handling of timezones as
commonly used in ical data and the standard tzurl.org repo.  It is
also completely backwards-compatible as far as I can make out.

Here's the README for the testcases I provided to Ulf along with the patch:

  This ZIP contains a patch for icalendar.el 0.19 and a set of iCalendar test files.
  VTIMEZONE sections contained therein were retrieved from http://tzurl.org.
 
   - Europe_Berlin-20181103T201500_no_in-calendar_VTIMEZONE.ics
     no VTIMEZONE, so no TZID references for DTSTART/DTEND, contains
     non-standard property X-WR-TIMEZONE which is invisible to icalendar.el
 
   - Europe_Berlin-20181103T201500_in-calendar_VTIMEZONE_tzurl_standard.ics
     standard VTIMEZONE ("Outlook-style")
 
   - Europe_Berlin-20181103T201500_in-calendar_VTIMEZONE_tzurl_historical.ics
     comprehensive VTIMEZONE including historical records
 
   - America_Creston-20181103T121500_in-calendar_VTIMEZONE_tzurl_standard.ics
     standard ("Outlook-style") VTIMEZONE
 
   - America_Creston-20181103T121500_in-calendar_VTIMEZONE_tzurl_historical_RDATE.ics
     comprehensive VTIMEZONE including historical records which use RDATE, not RRULE




Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Lars Ingebrigtsen
[hidden email] (Thomas Plass) writes:

> It fixes general issues with icalendar.el's handling of timezones as
> commonly used in ical data and the standard tzurl.org repo.  It is
> also completely backwards-compatible as far as I can make out.
>
> Here's the README for the testcases I provided to Ulf along with the patch:

Can you respin the patch and add the test cases to
test/lisp/calendar/icalendar-tests.el?  The icalendar test files should
go to a new test/data/icalendar directory, I guess.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
Am 11.08.2020 um 13:01 (+0200) schrieb Lars Ingebrigtsen:

> [hidden email] (Thomas Plass) writes:
>
>> It fixes general issues with icalendar.el's handling of timezones as
>> commonly used in ical data and the standard tzurl.org repo.  It is
>> also completely backwards-compatible as far as I can make out.
>>
>> Here's the README for the testcases I provided to Ulf along with the patch:
>
> Can you respin the patch and add the test cases to
> test/lisp/calendar/icalendar-tests.el?  The icalendar test files should
> go to a new test/data/icalendar directory, I guess.

IIRC icalendar-tests.el does not make use of the testdata directory.

Thomas, could you please provide the expected results for the test files,
one for each ics file?  Thanks!



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Lars Ingebrigtsen
Ulf Jasper <[hidden email]> writes:

> IIRC icalendar-tests.el does not make use of the testdata directory.

No, but I think it should.  :-)  At least when adding new tests -- it's
easier to be sure that we're really testing the right thing when we've
not stringified the icalendar data into a Lisp string...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
Am 11.08.2020 um 17:19 (+0200) schrieb Lars Ingebrigtsen:
> Ulf Jasper <[hidden email]> writes:
>
>> IIRC icalendar-tests.el does not make use of the testdata directory.
>
> No, but I think it should.  :-)  At least when adding new tests -- it's
> easier to be sure that we're really testing the right thing when we've
> not stringified the icalendar data into a Lisp string...

Agree.  icalendar-tests are hard to read.  sigh.




Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
In reply to this post by Ulf Jasper
Attached is an updated ZIP containing the respun patch and the
unmodified samples. The patch is against
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/calendar/icalendar.el
blob: d76c11050312b4a04ac1cbda436b3c08fc6f2cc5

Hopefully, this is OK as it is.

I also extended the README in the ZIP to clarify what the patch is about:

  The aim of the patch is to support robust date-time conversions based
  on the VTIMEZONE sections in the iCalendar data.  VTIMEZONE specifies
  the source timezone while the target timezone is supplied externally
  (by the OS, environment, user, etc).
 
  Assuming a target timezone of Europe/Berlin, the local start time of
  all events defined in the sample files is November 3, 2018 20:15h
  (20181103T201500).

Aside: the clerical (?) error in `icalendar--decode-isoduration' is
also part of the patch but has nothing to do with conversions.

Ulf Jasper wrote at 17:14 on August 11, 2020:
: Am 11.08.2020 um 13:01 (+0200) schrieb Lars Ingebrigtsen:
:
: Thomas, could you please provide the expected results for the test files,
: one for each ics file?  Thanks!

Well, the expected result depends on:

 - The local timezone of the person running the code.  Where I'm
   sitting, it is November 3, 2018 20:15h for all samples.  

   Europe_Berlin-20181103T201500_no_in-calendar_VTIMEZONE.ics contains
   no VTIMEZONE and thus has a somewhat undefined result.  The user
   agent is assumed to do the right thing based on OS/environment/user/AI.

   Note: this particular date+time is carefully chosen as it is
         subject to DST adjustments.  Under MS-Windows, it exercises
         Emacs' buggy DST handling.  But this fact is just incidental
         and not addressed by the patch.

 - Expectations as to how the conversion result is to be rendered.  In
   my case rendering of the iCal data is done by a MIME handler I
   cooked up for VM.  This is mainly used for rendering incoming
   meeting requests necessitating accurate date calculations.

Technical note: The concept of "target zone" is implemented by an
additional optional argument to `icalendar--decode-isodatetime'.  My
VM plugin's function for getting the event dates (inspired by
`icalendar--convert-ical-to-diary') says:

  (icalendar--decode-isodatetime dtstart nil dtstart-zone local-zone)

where there is a lot of apparatus for computing 'dtstart-zone and
'local-zone.  If you'd like to know more, I can send the code.




icalendar-patch+testcases_20200812.zip (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Lars Ingebrigtsen
[hidden email] (Thomas Plass) writes:

> Attached is an updated ZIP containing the respun patch and the
> unmodified samples. The patch is against
> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/calendar/icalendar.el
> blob: d76c11050312b4a04ac1cbda436b3c08fc6f2cc5
>
> Hopefully, this is OK as it is.

It would be better to add the test cases in the test/data directory and
add the tests as code to icalendar-tests.el...

> : Thomas, could you please provide the expected results for the test files,
> : one for each ics file?  Thanks!
>
> Well, the expected result depends on:
>
>  - The local timezone of the person running the code.  Where I'm
>    sitting, it is November 3, 2018 20:15h for all samples.  

(etc)

This is why the test cases should bind the time zone to whatever it is
it's testing -- that way we can easily ensure that the code continues to
work.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Thomas Plass
Lars Ingebrigtsen wrote at 15:12 on August 12, 2020:
:
: It would be better to add the test cases in the test/data directory and
: add the tests as code to icalendar-tests.el...

Certainly.  But apparently I'm too stupid to find that file and the
test/data dir.  Can someone send it to me?  As I have no commit
privileges and also am unable to build Emacs, I haven't checked out
the git.  So if the maintainer(s) could assist or extend the tests,
I'd be grateful.




Reply | Threaded
Open this post in threaded view
|

bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

Ulf Jasper
Am 12.08.2020 um 15:30 (+0200) schrieb Thomas Plass:

> Lars Ingebrigtsen wrote at 15:12 on August 12, 2020:
> :
> : It would be better to add the test cases in the test/data directory and
> : add the tests as code to icalendar-tests.el...
>
> Certainly.  But apparently I'm too stupid to find that file and the
> test/data dir.  Can someone send it to me?  As I have no commit
> privileges and also am unable to build Emacs, I haven't checked out
> the git.  So if the maintainer(s) could assist or extend the tests,
> I'd be grateful.

Don't worry.  I shall write or enhance the tests for the
icalendar-functions that you changed.  I shall also write tests that
check import of the ics files that you supplied.




12