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

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

[Thomas Plass]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2051 bytes --]

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



[-- Attachment #2: icalendar.el.patch --]
[-- Type: application/x-diff, Size: 5712 bytes --]

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

[Ulf Jasper]

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

Ulf

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

[Ulf Jasper]

Thomas,

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

Best,
ulf

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

[Thomas Plass]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 5275 bytes --]

[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


[-- Attachment #2: icalendar019-patch+testcases.zip --]
[-- Type: application/zip, Size: 6169 bytes --]

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

[Eli Zaretskii]

> Date: Mon, 18 Feb 2019 10:36:29 +0100
> From: thunk2@arcor.de (Thomas Plass)
> Cc: 34315@debbugs.gnu.org
> 
> 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.

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

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

[Eli Zaretskii]

> Date: Mon, 18 Feb 2019 20:15:19 +0100
> From: thunk2@arcor.de (Thomas Plass)
> Cc: 34315@debbugs.gnu.org
> 
> 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?

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?

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

[Eli Zaretskii]

> Date: Mon, 18 Feb 2019 21:03:15 +0100
> From: thunk2@arcor.de (Thomas Plass)
> Cc: 34315@debbugs.gnu.org
> 
> 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.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

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

This was over a year ago.

As far as I understand it, the patch itself is good and fixes a real
problem in icalendar date parsing?  But then the thread turned towards
questions about daylight savings time handling in Windows, and the patch
itself wasn't applied?

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

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

[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?

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

[Eli Zaretskii]

> From: Ulf Jasper <ulf.jasper@web.de>
> Cc: thunk2@arcor.de (Thomas Plass),  34315@debbugs.gnu.org
> 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.

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

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

[Lars Ingebrigtsen]

thunk2@arcor.de (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

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

[Ulf Jasper]

Am 11.08.2020 um 13:01 (+0200) schrieb Lars Ingebrigtsen:
> thunk2@arcor.de (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!

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> 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

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 <ulf.jasper@web.de> 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.

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

[Thomas Plass]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2440 bytes --]

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.




[-- Attachment #2: icalendar-patch+testcases_20200812.zip --]
[-- Type: application/zip, Size: 6457 bytes --]

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

[Lars Ingebrigtsen]

thunk2@arcor.de (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

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.

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.

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

[Ulf Jasper]

Just pushed two commits containing 1) unit tests and 2) your patch and
more tests.

I had to make a small change in the patched version of
`icalendar--decode-isodatetime' regarding input data in utc zone.
Please have a look.

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

[Thomas Plass]

Thanks, approved.  Defaulting to local time when decoding seems
reasonable.

Ulf Jasper wrote at 20:05 on September 2, 2020:
: I had to make a small change in the patched version of
: `icalendar--decode-isodatetime' regarding input data in utc zone.

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

[Ulf Jasper]

Thomas,

after committing your changes I learned that your contribution counts as
a non-trivial change that is sufficiently large to make a copyright
assignment necessary.

So, would you please assign the copyright for your contribution(s) to
the FSF?

In order to do this, please ask on emacs-devel@gnu.org, and we will send
you the necessary form together with the instructions to fill and email
it, in order to start this legal paperwork.

I should have asked you to assign copyright before I incorporated your
changes.  My mistake.  Sorry!

All the best,
Ulf

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

[Thomas Plass]

In case anyone is waiting:

Ulf Jasper wrote at 16:28 on September 3, 2020:
: 
: So, would you please assign the copyright for your contribution(s) to
: the FSF?

Seven days ago I returned the signed agreement to assign@gnu.org
cc'ing the FSF copyright clerk.  No reply since.  Presumably, the
assignment ("GNU EMACS") is in effect.

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

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 10:01:41 +0200
> From: thunk2@arcor.de (Thomas Plass)
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>     Eli Zaretskii <eliz@gnu.org>,
>     34315@debbugs.gnu.org
> 
> In case anyone is waiting:
> 
> Ulf Jasper wrote at 16:28 on September 3, 2020:
> : 
> : So, would you please assign the copyright for your contribution(s) to
> : the FSF?
> 
> Seven days ago I returned the signed agreement to assign@gnu.org
> cc'ing the FSF copyright clerk.  No reply since.  Presumably, the
> assignment ("GNU EMACS") is in effect.

Not yet, AFAICT.  if you get no responses in another week, please ping
them and CC me.

Thanks.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Seven days ago I returned the signed agreement to assign@gnu.org
  > cc'ing the FSF copyright clerk.  No reply since.  Presumably, the
  > assignment ("GNU EMACS") is in effect.

It ought to be, but we should wait for confirmation.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Thomas Plass]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 676 bytes --]

Two pieces of news:

 - as of yesterday, my assignment/disclaimer process with the FSF has
   been completed

 - in celebration, I'd like to submit yet another patch that extends
   icalendar.el's timezone handling, this one intended to support
   regions that at some point in the past made a permanent switch from
   a DST/STD scheme to STD-only/DST-only.  Cases in point are China
   and Turkey,
   cf. https://en.wikipedia.org/wiki/Daylight_saving_time_in_Asia.

   Ulf, would you care to review the code and the included test cases?


Ulf Jasper wrote at 16:28 on September 3, 2020:
: 
: So, would you please assign the copyright for your contribution(s) to
: the FSF?



[-- Attachment #2: icalendar-patch2+testcases_20200924.zip --]
[-- Type: application/zip, Size: 6044 bytes --]

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

thunk2@arcor.de (Thomas Plass) writes:

>  - in celebration, I'd like to submit yet another patch that extends
>    icalendar.el's timezone handling, this one intended to support
>    regions that at some point in the past made a permanent switch from
>    a DST/STD scheme to STD-only/DST-only.  Cases in point are China
>    and Turkey,
>    cf. https://en.wikipedia.org/wiki/Daylight_saving_time_in_Asia.
>
>    Ulf, would you care to review the code and the included test cases?

Thanks for the code.  It was in slightly inconvenient format -- we
prefer just simple patches, so I've reformatted it as such below.

However, the code makes two tests fail:

2 unexpected results:
   FAILED  icalendar--convert-tz-offset
   FAILED  icalendar--parse-vtimezone

I haven't actually looked at the failing cases, though.

In addition, the test cases included aren't actually used?  Could you
propose some code to use them?  (It should go in
test/lisp/calendar/icalendar-tests.el.)

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: icalendar.patch --]
[-- Type: text/x-diff, Size: 18249 bytes --]

diff --git a/lisp/calendar/icalendar.el b/lisp/calendar/icalendar.el
index dab277487e..e4760db3e4 100644
--- a/lisp/calendar/icalendar.el
+++ b/lisp/calendar/icalendar.el
@@ -519,46 +519,56 @@ icalendar--convert-tz-offset
 	 (dtstart (car (cddr (assq 'DTSTART alist))))
 	 (no-dst (or rdate-p (equal offsetto offsetfrom))))
     ;; FIXME: the presence of an RDATE is assumed to denote the first day of the year
-    (when (and offsetto dtstart (or rrule-value no-dst))
-      (let* ((rrule (icalendar--split-value rrule-value))
-	     (freq (cadr (assq 'FREQ rrule)))
-	     (bymonth (cadr (assq 'BYMONTH rrule)))
-	     (byday (cadr (assq 'BYDAY rrule))))
-	;; FIXME: we don't correctly handle WKST here.
-	(if (or no-dst (and (string= freq "YEARLY") bymonth))
-	    (cons
-	     (concat
-	      ;; Fake a name.
-	      (if dst-p "DST" "STD")
-	      ;; For TZ, OFFSET is added to the local time.  So,
-	      ;; invert the values.
-	      (if (eq (aref offsetto 0) ?-) "+" "-")
-	      (substring offsetto 1 3)
-	      ":"
-	      (substring offsetto 3 5))
-	     ;; The start time.
-             (let* ((day (if no-dst
-                             1
-                           (icalendar--get-weekday-number (substring byday -2))))
-                    (week (if no-dst
-                              "1"
-                            (if (eq day -1)
-				byday
-			      (substring byday 0 -2)))))
-		 ;; "Translate" the iCalendar way to specify the last
-		 ;; (sun|mon|...)day in month to the tzset way.
-		 (if (string= week "-1")  ; last day as iCalendar calls it
+    (if (and offsetto dtstart (or rrule-value no-dst))
+        (let* ((rrule (icalendar--split-value rrule-value))
+	       (freq (cadr (assq 'FREQ rrule)))
+	       (bymonth (cadr (assq 'BYMONTH rrule)))
+	       (byday (cadr (assq 'BYDAY rrule))))
+	  ;; FIXME: we don't correctly handle WKST here.
+	  (if (or no-dst (and (string= freq "YEARLY") bymonth))
+	      (cons
+	       (concat
+	        ;; Fake a name.
+	        (if dst-p "DST" "STD")
+	        ;; For TZ, OFFSET is added to the local time.  So,
+	        ;; invert the values.
+	        (if (eq (aref offsetto 0) ?-) "+" "-")
+	        (substring offsetto 1 3)
+	        ":"
+	        (substring offsetto 3 5))
+	       ;; The start time.
+               (let* ((day (if no-dst
+                               1
+                             (icalendar--get-weekday-number (substring byday -2))))
+                      (week (if no-dst
+                                "1"
+                              (if (eq day -1)
+				  byday
+			        (substring byday 0 -2)))))
+	         ;; "Translate" the iCalendar way to specify the last
+	         ;; (sun|mon|...)day in month to the tzset way.
+	         (if (string= week "-1")  ; last day as iCalendar calls it
 		     (setq week "5"))     ; last day as tzset calls it
                  (when no-dst (setq bymonth "1"))
 		 (concat "M" bymonth "." week "." (if (eq day -1) "0"
 						    (int-to-string day))
-			 ;; Start time.
-			 "/"
-			 (substring dtstart -6 -4)
-			 ":"
-			 (substring dtstart -4 -2)
-			 ":"
-			 (substring dtstart -2)))))))))
+		         ;; Start time.
+		         "/"
+		         (substring dtstart -6 -4)
+		         ":"
+		         (substring dtstart -4 -2)
+		         ":"
+		         (substring dtstart -2))))))
+      ;; neither RRULE nor RDATE present: return the offset and a placeholder
+      (cons
+       (concat
+	;; Fake a name.
+	(if dst-p "DST" "STD")
+	(if (eq (aref offsetto 0) ?-) "+" "-")
+	(substring offsetto 1 3)
+	":"
+	(substring offsetto 3 5))
+       dtstart))))
 
 (defun icalendar--parse-vtimezone (alist)
   "Turn a VTIMEZONE ALIST into a cons (ID . TZ-STRING).
@@ -571,34 +581,59 @@ icalendar--parse-vtimezone
 	 (standard (cadr (cdar (icalendar--get-most-recent-observance alist 'STANDARD))))
 	 (std (and standard (icalendar--convert-tz-offset standard nil))))
     (if (and tz-id std)
-	(cons tz-id
-	      (if day
-		  (concat (car std) (car day)
-			  "," (cdr day) "," (cdr std))
-		(car std))))))
+        (cons tz-id
+              (if (and (not (assq 'RRULE daylight))
+                       (not (assq 'RRULE standard)))
+                  (let ((daylight-rdate (and (assq 'RDATE daylight)
+                                             (icalendar--get-most-recent-observance-from-sub-comp
+                                              daylight
+                                              '(RDATE))))
+                        (standard-rdate (and (assq 'RDATE standard)
+                                             (icalendar--get-most-recent-observance-from-sub-comp
+                                              standard
+                                              '(RDATE)))))
+                    (if (and daylight-rdate
+                             standard-rdate
+                             (string-greaterp daylight-rdate standard-rdate))
+                        (car day)
+                      (car std)))
+	        (if day
+		    (concat (car std) (car day)
+			    "," (cdr day) "," (cdr std))
+		  (car std)))))))
 
 (defun icalendar--get-most-recent-observance (alist sub-comp)
-  "Return the latest observance for SUB-COMP DAYLIGHT or STANDARD.
+  "Return the latest observance of all SUB-COMPs DAYLIGHT or STANDARD.
 ALIST is a VTIMEZONE potentially containing historical records."
-;FIXME?: "most recent" should be relative to a given date
+;FIXME: "most recent" should be relative to a given date and
+;       avoid selecting a SUB-COMP valid for dates in the future.
   (let ((components (icalendar--get-children alist sub-comp)))
     (list
      (car
       (sort components
             #'(lambda (a b)
-                (let* ((get-recent (lambda (n)
-                                     (car
-                                      (sort
-                                       (delq nil
-                                             (mapcar (lambda (p)
-                                                       (and (memq (car p) '(DTSTART RDATE))
-                                                            (car (cddr p))))
-                                                     n))
-                                       'string-greaterp))))
-                       (a-recent (funcall get-recent (car (cddr a))))
-                       (b-recent (funcall get-recent (car (cddr b)))))
+                (let* ((a-recent (icalendar--get-most-recent-observance-from-sub-comp
+                                  (car (cddr a))
+                                  '(DTSTART RDATE)))
+                       (b-recent (icalendar--get-most-recent-observance-from-sub-comp
+                                  (car (cddr b))
+                                  '(DTSTART RDATE))))
                   (string-greaterp a-recent b-recent))))))))
 
+(defun icalendar--get-most-recent-observance-from-sub-comp (alist sym-list)
+  "Return the latest observance for ALIST DAYLIGHT or STANDARD.
+ALIST is an individual DAYLIGHT or STANDARD.
+SYM-LIST is a list of property names DTSTART and/or RDATE
+for filtering ALIST."
+  (car
+   (sort
+    (delq nil
+          (mapcar (lambda (p)
+                    (when (memq (car p) sym-list)
+                      (car (cddr p))))
+                  alist))
+    'string-greaterp)))
+
 (defun icalendar--convert-all-timezones (icalendar)
   "Convert all timezones in the ICALENDAR into an alist.
 Each element of the alist is a cons (ID . TZ-STRING),
diff --git a/test/lisp/calendar/icalendar-resources/Asia_Istanbul_20200924T120000_in-calendar_VTIMEZONE_tzurl_org.ics b/test/lisp/calendar/icalendar-resources/Asia_Istanbul_20200924T120000_in-calendar_VTIMEZONE_tzurl_org.ics
new file mode 100644
index 0000000000..6425909be6
--- /dev/null
+++ b/test/lisp/calendar/icalendar-resources/Asia_Istanbul_20200924T120000_in-calendar_VTIMEZONE_tzurl_org.ics
@@ -0,0 +1,219 @@
+BEGIN:VCALENDAR

+PRODID:manual

+VERSION:2.0

+BEGIN:VTIMEZONE

+TZID:Asia/Istanbul

+TZURL:http://tzurl.org/zoneinfo/Asia/Istanbul

+X-LIC-LOCATION:Asia/Istanbul

+BEGIN:STANDARD

+TZOFFSETFROM:+015552

+TZOFFSETTO:+015656

+TZNAME:IMT

+DTSTART:18800101T000000

+RDATE:18800101T000000

+END:STANDARD

+BEGIN:STANDARD

+TZOFFSETFROM:+015656

+TZOFFSETTO:+0200

+TZNAME:EET

+DTSTART:19101001T000000

+RDATE:19101001T000000

+END:STANDARD

+BEGIN:DAYLIGHT

+TZOFFSETFROM:+0200

+TZOFFSETTO:+0300

+TZNAME:EEST

+DTSTART:19160501T000000

+RDATE:19160501T000000

+RDATE:19200328T000000

+RDATE:19210403T000000

+RDATE:19220326T000000

+RDATE:19240513T000000

+RDATE:19250501T000000

+RDATE:19400630T000000

+RDATE:19401201T000000

+RDATE:19420401T000000

+RDATE:19450402T000000

+RDATE:19460601T000000

+RDATE:19470420T000000

+RDATE:19480418T000000

+RDATE:19490410T000000

+RDATE:19500419T000000

+RDATE:19510422T000000

+RDATE:19620715T000000

+RDATE:19640515T000000

+RDATE:19700503T000000

+RDATE:19710502T000000

+RDATE:19720507T000000

+RDATE:19730603T010000

+RDATE:19740331T020000

+RDATE:19750330T000000

+RDATE:19760601T000000

+RDATE:19770403T000000

+RDATE:19780402T000000

+RDATE:19860330T010000

+RDATE:19870329T010000

+RDATE:19880327T010000

+RDATE:19890326T010000

+RDATE:19900325T010000

+RDATE:19910331T010000

+RDATE:19920329T010000

+RDATE:19930328T010000

+RDATE:19940320T010000

+RDATE:19950326T010000

+RDATE:19960331T010000

+RDATE:19970330T010000

+RDATE:19980329T010000

+RDATE:19990328T010000

+RDATE:20000326T010000

+RDATE:20010325T010000

+RDATE:20020331T010000

+RDATE:20030330T010000

+RDATE:20040328T010000

+RDATE:20050327T010000

+RDATE:20060326T010000

+RDATE:20070325T030000

+RDATE:20080330T030000

+RDATE:20090329T030000

+RDATE:20100328T030000

+RDATE:20110328T030000

+RDATE:20120325T030000

+RDATE:20130331T030000

+RDATE:20140331T030000

+RDATE:20150329T030000

+RDATE:20160327T030000

+END:DAYLIGHT

+BEGIN:STANDARD

+TZOFFSETFROM:+0300

+TZOFFSETTO:+0200

+TZNAME:EET

+DTSTART:19161001T000000

+RDATE:19161001T000000

+RDATE:19201025T000000

+RDATE:19211003T000000

+RDATE:19221008T000000

+RDATE:19241001T000000

+RDATE:19251001T000000

+RDATE:19401005T000000

+RDATE:19410921T000000

+RDATE:19421101T000000

+RDATE:19451008T000000

+RDATE:19461001T000000

+RDATE:19471005T000000

+RDATE:19481003T000000

+RDATE:19491002T000000

+RDATE:19501008T000000

+RDATE:19511008T000000

+RDATE:19621008T000000

+RDATE:19641001T000000

+RDATE:19701004T000000

+RDATE:19711003T000000

+RDATE:19721008T000000

+RDATE:19731104T030000

+RDATE:19741103T050000

+RDATE:19751026T000000

+RDATE:19761031T000000

+RDATE:19771016T000000

+RDATE:19850928T000000

+RDATE:19860928T020000

+RDATE:19870927T020000

+RDATE:19880925T020000

+RDATE:19890924T020000

+RDATE:19900930T020000

+RDATE:19910929T020000

+RDATE:19920927T020000

+RDATE:19930926T020000

+RDATE:19940925T020000

+RDATE:19950924T020000

+RDATE:19961027T020000

+RDATE:19971026T020000

+RDATE:19981025T020000

+RDATE:19991031T020000

+RDATE:20001029T020000

+RDATE:20011028T020000

+RDATE:20021027T020000

+RDATE:20031026T020000

+RDATE:20041031T020000

+RDATE:20051030T020000

+RDATE:20061029T020000

+RDATE:20071028T040000

+RDATE:20081026T040000

+RDATE:20091025T040000

+RDATE:20101031T040000

+RDATE:20111030T040000

+RDATE:20121028T040000

+RDATE:20131027T040000

+RDATE:20141026T040000

+END:STANDARD

+BEGIN:DAYLIGHT

+TZOFFSETFROM:+0300

+TZOFFSETTO:+0400

+TZNAME:+04

+DTSTART:19781015T000000

+RDATE:19781015T000000

+RDATE:19800406T030000

+RDATE:19810329T030000

+RDATE:19820328T030000

+RDATE:19830731T000000

+END:DAYLIGHT

+BEGIN:DAYLIGHT

+TZOFFSETFROM:+0400

+TZOFFSETTO:+0400

+TZNAME:+04

+DTSTART:19790401T030000

+RDATE:19790401T030000

+END:DAYLIGHT

+BEGIN:STANDARD

+TZOFFSETFROM:+0400

+TZOFFSETTO:+0300

+TZNAME:+03

+DTSTART:19791015T000000

+RDATE:19791015T000000

+RDATE:19801013T000000

+RDATE:19811012T000000

+RDATE:19821011T000000

+RDATE:19831002T000000

+END:STANDARD

+BEGIN:DAYLIGHT

+TZOFFSETFROM:+0300

+TZOFFSETTO:+0300

+TZNAME:EEST

+DTSTART:19850420T000000

+RDATE:19850420T000000

+RDATE:20151025T040000

+END:DAYLIGHT

+BEGIN:STANDARD

+TZOFFSETFROM:+0200

+TZOFFSETTO:+0200

+TZNAME:EET

+DTSTART:20070101T000000

+RDATE:20070101T000000

+RDATE:20110327T030000

+RDATE:20140330T030000

+END:STANDARD

+BEGIN:STANDARD

+TZOFFSETFROM:+0300

+TZOFFSETTO:+0200

+DTSTART:20151108T040000

+RDATE:20151108T040000

+END:STANDARD

+BEGIN:STANDARD

+TZOFFSETFROM:+0300

+TZOFFSETTO:+0300

+TZNAME:+03

+DTSTART:20160907T000000

+RDATE:20160907T000000

+END:STANDARD

+END:VTIMEZONE

+BEGIN:VEVENT

+CLASS:PUBLIC

+DTSTART;TZID=Asia/Istanbul:20200924T120000

+DTEND;TZID=Asia/Istanbul:20200924T130000

+UID:Asia_Istanbul_20200924T120000_in-calendar_VTIMEZONE_tzurl_org.ics

+DTSTAMP:20190127T140400

+DESCRIPTION:date 2020-09-24, Istanbul local time 12:00 UTC+3, in-calendar

+  VTIMEZONE as returned by http://tzurl.org/zoneinfo/Asia/Istanbul

+SUMMARY:date 2020-09-24, Istanbul local time 12:00 UTC+3, in-calendar

+  VTIMEZONE as returned by http://tzurl.org/zoneinfo/Asia/Istanbul

+END:VEVENT

+END:VCALENDAR

diff --git a/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_multi_DAYLIGHT_STANDARD.ics b/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_multi_DAYLIGHT_STANDARD.ics
new file mode 100644
index 0000000000..26dd3cbfb8
--- /dev/null
+++ b/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_multi_DAYLIGHT_STANDARD.ics
@@ -0,0 +1,116 @@
+BEGIN:VCALENDAR

+PRODID:manual

+VERSION:2.0

+CALSCALE:GREGORIAN

+METHOD:PUBLISH

+BEGIN:VTIMEZONE

+TZID:Asia/Shanghai

+X-LIC-LOCATION:Asia/Shanghai

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19411001T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19860504T000000

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19860914T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19870412T000000

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19870913T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19880410T000000

+TZOFFSETFROM:+0800

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19880911T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19890416T000000

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19890917T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19900415T000000

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19900916T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+BEGIN:DAYLIGHT

+TZNAME:CDT

+DTSTART:19910414T000000

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+END:DAYLIGHT

+BEGIN:STANDARD

+TZNAME:CST

+DTSTART:19910915T000000

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+END:STANDARD

+END:VTIMEZONE

+BEGIN:VTIMEZONE

+TZID:Etc/UTC

+X-LIC-LOCATION:Etc/UTC

+BEGIN:STANDARD

+TZNAME:UTC

+DTSTART:19700101T000000

+TZOFFSETFROM:+0000

+TZOFFSETTO:+0000

+END:STANDARD

+END:VTIMEZONE

+BEGIN:VEVENT

+CLASS:PUBLIC

+DTSTART;TZID=Asia/Shanghai:20200916T070000

+DTEND;TZID=Asia/Shanghai:20200916T080000

+UID:Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_multi_DAYLIGHT_STANDARD.ics

+DTSTAMP:20190127T140400

+DESCRIPTION:date 2020-09-16, Shanghai local time 07:00 UTC+8, in-calendar

+  VTIMEZONE with multiple DAYLIGHT and STANDARD sub-components, cf.

+ https://techcommunity.microsoft.com/t5/office-365/import-ics-to-office-365

+ -calendar-but-the-event-time-is-wrong/td-p/215332

+SUMMARY:date 2020-09-16, Shanghai local time 07:00 UTC+8, in-calendar

+  VTIMEZONE with multiple DAYLIGHT and STANDARD sub-components, cf.

+ https://techcommunity.microsoft.com/t5/office-365/import-ics-to-office-365

+ -calendar-but-the-event-time-is-wrong/td-p/215332

+END:VEVENT

+END:VCALENDAR

+

+ 

diff --git a/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics b/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics
new file mode 100644
index 0000000000..ccd39bd114
--- /dev/null
+++ b/test/lisp/calendar/icalendar-resources/Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics
@@ -0,0 +1,65 @@
+BEGIN:VCALENDAR

+PRODID:manual

+VERSION:2.0

+BEGIN:VTIMEZONE

+TZID:Asia/Shanghai

+TZURL:http://tzurl.org/zoneinfo/Asia/Shanghai

+X-LIC-LOCATION:Asia/Shanghai

+BEGIN:STANDARD

+TZOFFSETFROM:+080543

+TZOFFSETTO:+0800

+TZNAME:CST

+DTSTART:19010101T000000

+RDATE:19010101T000000

+END:STANDARD

+BEGIN:DAYLIGHT

+TZOFFSETFROM:+0800

+TZOFFSETTO:+0900

+TZNAME:CDT

+DTSTART:19400601T000000

+RDATE:19400601T000000

+RDATE:19410315T000000

+RDATE:19420131T000000

+RDATE:19460515T000000

+RDATE:19470415T000000

+RDATE:19480501T000000

+RDATE:19490501T000000

+RDATE:19860504T020000

+RDATE:19870412T020000

+RDATE:19880417T020000

+RDATE:19890416T020000

+RDATE:19900415T020000

+RDATE:19910414T020000

+END:DAYLIGHT

+BEGIN:STANDARD

+TZOFFSETFROM:+0900

+TZOFFSETTO:+0800

+TZNAME:CST

+DTSTART:19401012T235959

+RDATE:19401012T235959

+RDATE:19411101T235959

+RDATE:19450901T235959

+RDATE:19460930T235959

+RDATE:19471031T235959

+RDATE:19480930T235959

+RDATE:19490528T000000

+RDATE:19860914T020000

+RDATE:19870913T020000

+RDATE:19880911T020000

+RDATE:19890917T020000

+RDATE:19900916T020000

+RDATE:19910915T020000

+END:STANDARD

+END:VTIMEZONE

+BEGIN:VEVENT

+CLASS:PUBLIC

+DTSTART;TZID=Asia/Shanghai:20200916T070000

+DTEND;TZID=Asia/Shanghai:20200916T080000

+UID:Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics

+DTSTAMP:20190127T140400

+DESCRIPTION:date 2020-09-16, Shanghai local time 07:00 UTC+8, in-calendar

+  VTIMEZONE as returned by http://tzurl.org/zoneinfo/Asia/Shanghai

+SUMMARY:date 2020-09-16, Shanghai local time 07:00 UTC+8, in-calendar

+  VTIMEZONE as returned by http://tzurl.org/zoneinfo/Asia/Shanghai

+END:VEVENT

+END:VCALENDAR

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

[Lars Ingebrigtsen]

Oops, the example files didn't survive sending like this -- the CRLF was
translated into two newlines?  

+  VTIMEZONE as returned by http://tzurl.org/zoneinfo/Asia/Shanghai

+END:VEVENT

+END:VCALENDAR

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

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

[Thomas Plass]

Lars Ingebrigtsen wrote at 03:45 on October 1, 2020:
: 
: However, the code makes two tests fail:

Like with the previous patch, I hoped to get away with offloading the
testing part to the maintainer... But the failures prompted me to get
familiar with the test setup for the two culprits.

: 2 unexpected results:
:    FAILED  icalendar--convert-tz-offset
:    FAILED  icalendar--parse-vtimezone

My latest patch requires some test definitions to be modified as well
as existing commented out code to be commented in.

Background: In light of the way an abandonment of daylight saving time
is expressed in VTIMEZONE, my patch will always make sure that - when
no recurrence rules RRULE are specified - the (most recent) UTC offset
of the most recent DAYLIGHT or STANDARD is returned.  This offset is
what counts, IMHO.  Computing and using a TZ spec - even a default one
- seems inappropriate for theses cases.

: In addition, the test cases included aren't actually used?

Implicitly, they are when my patch to icalendar-tests.el (below, not a
--git, sorry) is applied.  The raw ICS data seem rather large for
incorporation into the Lisp code.

But I'd rather let Ulf have the final say about the patches and how
the data is to be tested.


----------------------------------------------------------------------
diff -Naur icalendar-tests.el.bce7de769e0c024b26729c45c2c27c7f3749c499 icalendar-tests.el
--- icalendar-tests.el.bce7de769e0c024b26729c45c2c27c7f3749c499	2020-10-01 12:59:40.051753100 +0200
+++ icalendar-tests.el	2020-10-01 14:04:42.106937900 +0200
@@ -248,7 +248,7 @@
     (setq result (icalendar--parse-vtimezone vtimezone))
     (should (string= "Kolkata, Chennai, Mumbai, New Delhi" (car result)))
     (message (cdr result))
-    (should (string= "STD-05:30DST-05:30,M1.1.1/00:00:00,M1.1.1/00:00:00"
+    (should (string= "STD-05:30"
                      (cdr result)))
 
     ;; FIXME: add testcase that covers changes for fix of bug#34315
@@ -557,28 +557,29 @@
                             (RRULE nil "FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU"))
                           t)))
 
-          ;; testcase: dtstart is mandatory
-          (should (null (icalendar--convert-tz-offset
+          ;; testcase: dtstart is mandatory but if not set return at least the offset
+          (should (equal '("DST-02:00")
+                         (icalendar--convert-tz-offset
                           '((TZOFFSETFROM nil "+0100")
                             (TZOFFSETTO nil "+0200")
                             (RRULE nil "FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU"))
                           t)))
 
-          ;; FIXME: rrule and rdate are NOT mandatory!  Must fix code
-          ;; before activating these testcases
-          ;; ;; testcase: no rrule and no rdate => no result
-          ;; (should (null (icalendar--convert-tz-offset
-          ;;                 '((TZOFFSETFROM nil "+0100")
-          ;;                   (TZOFFSETTO nil "+0200")
-          ;;                   (DTSTART nil "19700329T020000"))
-          ;;                 t)))
-          ;; ;; testcase: no rrule with rdate => no result
-          ;; (should (null (icalendar--convert-tz-offset
-          ;;                 '((TZOFFSETFROM nil "+0100")
-          ;;                   (TZOFFSETTO nil "+0200")
-          ;;                   (DTSTART nil "18840101T000000")
-          ;;                   (RDATE nil "18840101T000000"))
-          ;;                 t)))
+          ;; rrule and rdate are NOT mandatory: return the offset and a placeholder
+          (should (equal '("DST-02:00" . "19700329T020000")
+                         (icalendar--convert-tz-offset
+                          '((TZOFFSETFROM nil "+0100")
+                            (TZOFFSETTO nil "+0200")
+                            (DTSTART nil "19700329T020000"))
+                          t)))
+          ;; ;; testcase: no rrule with rdate => return offset and a default TZ spec
+          (should (equal '("DST-02:00" . "M1.1.1/00:00:00")
+                         (icalendar--convert-tz-offset
+                          '((TZOFFSETFROM nil "+0100")
+                            (TZOFFSETTO nil "+0200")
+                            (DTSTART nil "18840101T000000")
+                            (RDATE nil "18840101T000000"))
+                          t)))
           )
       ;; restore time-zone even if something went terribly wrong
       (setenv "TZ" tz))))

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

[Ulf Jasper]

Am 01.10.2020 um 16:38 (+0300) schrieb Thomas Plass:

> But I'd rather let Ulf have the final say about the patches and how
> the data is to be tested.

I agree with Lars here. (Thank you, Lars, for your investigation!)

When patching icalendar.el (or any other file) one must make sure that
the corresponding unit tests do not fail.  If necessary the unit tests
need to be adjusted.  If possible one should add unit tests so that all
code changes get covered.  (And so on -- the usual ideas behind unit
tests.)

It looks like your patch of 'icalendar-tests.el' does not contain
the samples from the ics files.  Could you please add these?

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> It looks like your patch of 'icalendar-tests.el' does not contain
> the samples from the ics files.  Could you please add these?

I think putting the sample .ics files in a separate icalendar-resources
directory is the way forward...

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

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

[Ulf Jasper]

Am 01.10.2020 um 18:22 (+0200) schrieb Lars Ingebrigtsen:
> Ulf Jasper <ulf.jasper@web.de> writes:
>
>> It looks like your patch of 'icalendar-tests.el' does not contain
>> the samples from the ics files.  Could you please add these?
>
> I think putting the sample .ics files in a separate icalendar-resources
> directory is the way forward...

Currently there is no way to use ics files in icalendar-tests.  In the
past we've extracted the relevant handful of lines from such a file and
constructed a testcase from such files.  ics files might be useful for
the "real world tests" though.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> Currently there is no way to use ics files in icalendar-tests.  In the
> past we've extracted the relevant handful of lines from such a file and
> constructed a testcase from such files.  ics files might be useful for
> the "real world tests" though.

Why can't ics files be used from icalendar-tests?

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

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

[Ulf Jasper]

Am 01.10.2020 um 18:59 (+0200) schrieb Lars Ingebrigtsen:

> Why can't ics files be used from icalendar-tests?

Because it has not been implemented.

Right now 'icalendar-tests.el' contains input data together with the
corresponding expected results.  When we move input data into separate
files, we should do the same for the expected results.  For each ics
file there should be a corresponding expected-result file.  That's not a
big deal.  It just has not been done yet.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> Am 01.10.2020 um 18:59 (+0200) schrieb Lars Ingebrigtsen:
>
>> Why can't ics files be used from icalendar-tests?
>
> Because it has not been implemented.
>
> Right now 'icalendar-tests.el' contains input data together with the
> corresponding expected results.  When we move input data into separate
> files, we should do the same for the expected results.  For each ics
> file there should be a corresponding expected-result file.  That's not a
> big deal.  It just has not been done yet.

Oh, OK, I thought you meant there was something somehow fundamentally
precluding putting the ics data into files.

But surely not all the tests are transforms in this way.  Reading an ics
file and having a test that says "what's the meeting time in this file?"
should be a fine test, right?

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

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

[Thomas Plass]

I'd like to get some guidance from people involved on the following proposal:

Ulf Jasper wrote at 18:54 on October 1, 2020:

: Currently there is no way to use ics files in icalendar-tests.

Would it be acceptable to:

  - create a directory root/test/lisp/calendar/icalendar-resources

  - extend icalendar-tests.el with the following:

    (defvar icalendar-resources-directory "icalendar-resources"
      "Name of directory containing ICS files.
    This directory is relative to icalendar-tests.el.")
    
    (defun icalendar-tests--get-ical-from-file (ics-file &optional component)
      "Return iCalendar data structures from ICS-FILE.
    Optional symbol COMPONENT names a top-level component like 'VTIMEZONE."
      (let (ical)
        (if (file-exists-p ics-file)
            (save-excursion
              (with-temp-buffer
                (insert-file-contents ics-file)
                (goto-char (point-min))
                (setq ical (car (icalendar--read-element nil nil)))
                (if component
                    (setq res (car (icalendar--get-children ical component)))
                  (setq res ical))))
          (error "Can't find ICS file %s" ics-file))))


Which could be used thusly in the definition of 'icalendar--parse-vtimezone:

(ert-deftest icalendar--parse-vtimezone ()
  "Test method for `icalendar--parse-vtimezone'."
  (let (vtimezone result)

    (setq vtimezone (icalendar-tests--get-ical-from-file
                     (concat (file-name-as-directory icalendar-resources-directory)
                             "Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics")
                     'VTIMEZONE))
    (setq result (icalendar--parse-vtimezone vtimezone))
    (should (string= "Asia/Shanghai" (car result)))
    (message (cdr result))
    (should (string= "STD-08:00"
                        (cdr result)))     


  ...
  ))


I have no idea how the test code is run, in particular how

  (concat (file-name-as-directory icalendar-resources-directory)
          "Asia_Shanghai_20200916T070000_in-calendar_VTIMEZONE_tzurl_org.ics")

could be made to resolve.

Also, I cannot alter the git.

Please advise.

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

[Thomas Plass]

Cleaned up version:

(defun icalendar-tests--get-ical-from-file (ics-file &optional component)
  "Return iCalendar data structures from ICS-FILE.
Optional symbol COMPONENT names a top-level component like 'VTIMEZONE."
  (let (ical)
    (if (file-exists-p ics-file)
        (save-excursion
          (with-temp-buffer
            (insert-file-contents ics-file)
            (goto-char (point-min))
            (setq ical (car (icalendar--read-element nil nil)))
            (if component
                (car (icalendar--get-children ical component))
              ical)))
      (error "Can't find ICS file %s" ics-file))))



Thomas Plass wrote at 21:49 on October 1, 2020:
: 
:   - extend icalendar-tests.el with the following:
: 
:     (defvar icalendar-resources-directory "icalendar-resources"
:       "Name of directory containing ICS files.
:     This directory is relative to icalendar-tests.el.")
:     
:     (defun icalendar-tests--get-ical-from-file (ics-file &optional component)
:       "Return iCalendar data structures from ICS-FILE.
:     Optional symbol COMPONENT names a top-level component like 'VTIMEZONE."
:       (let (ical)
:         (if (file-exists-p ics-file)
:             (save-excursion
:               (with-temp-buffer
:                 (insert-file-contents ics-file)
:                 (goto-char (point-min))
:                 (setq ical (car (icalendar--read-element nil nil)))
:                 (if component
:                     (setq res (car (icalendar--get-children ical component)))
:                   (setq res ical))))
:           (error "Can't find ICS file %s" ics-file))))

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

[Ulf Jasper]

Am 01.10.2020 um 20:47 (+0200) schrieb Lars Ingebrigtsen:

> But surely not all the tests are transforms in this way.  Reading an ics
> file and having a test that says "what's the meeting time in this file?"
> should be a fine test, right?

Basically icalendar.el just does transformations from ics to Emacs diary
and vice versa.  Correspondingly icalendar-tests consist of import and
export tests plus tests of lower-level functions.  The file based
approach would apply to the im-/export tests only.

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

[Ulf Jasper]

Am 01.10.2020 um 21:49 (+0300) schrieb Thomas Plass:
> I'd like to get some guidance from people involved on the following
> proposal:

That is close to what I have in mind.  When we out-source test input
data, we should do the same with the corresponding expected results.  A
unit test case would look something like this.

- read input data from ics file
- read expected result from corresponding file
- perform action under test on input data
- compare result with previously read expected result

I could write the necessary helper functions and then, for a start,
apply this scheme to the "real world" tests in icalendar-tests.el.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> - read input data from ics file
> - read expected result from corresponding file
> - perform action under test on input data
> - compare result with previously read expected result
>
> I could write the necessary helper functions and then, for a start,
> apply this scheme to the "real world" tests in icalendar-tests.el.

Sounds like a good plan to me.

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

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

[Ulf Jasper]

Sorry for the long delays on my side.

I moved the test data out of icalendar-tests.el into separate files.
The first step is done.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

> Sorry for the long delays on my side.
>
> I moved the test data out of icalendar-tests.el into separate files.
> The first step is done.

Looks good.

Re-skimming this thread, it seems to me that the reported problem hasn't
been fixed?  (But I may be completely wrong about that.)  If that's the
case, has there been any progress on integrating Thomas' patch?

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

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

[Ulf Jasper]

Am 11.05.2021 um 16:10 (+0200) schrieb Lars Ingebrigtsen:
> Ulf Jasper <ulf.jasper@web.de> writes:
>> I moved the test data out of icalendar-tests.el into separate files.
>> The first step is done.
>
> Looks good.
>
> Re-skimming this thread, it seems to me that the reported problem hasn't
> been fixed?  (But I may be completely wrong about that.)  If that's the
> case, has there been any progress on integrating Thomas' patch?

IIRC the next step would be to add test files, i.e. ics files holding
input files and diary files holding expected output data.  But maybe I
am mistaken.

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

[Lars Ingebrigtsen]

Ulf Jasper <ulf.jasper@web.de> writes:

>> Re-skimming this thread, it seems to me that the reported problem hasn't
>> been fixed?  (But I may be completely wrong about that.)  If that's the
>> case, has there been any progress on integrating Thomas' patch?
>
> IIRC the next step would be to add test files, i.e. ics files holding
> input files and diary files holding expected output data.  But maybe I
> am mistaken.

That's also my understanding.

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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ulf Jasper <ulf.jasper@web.de> writes:
>
>> - read input data from ics file
>> - read expected result from corresponding file
>> - perform action under test on input data
>> - compare result with previously read expected result
>>
>> I could write the necessary helper functions and then, for a start,
>> apply this scheme to the "real world" tests in icalendar-tests.el.
>
> Sounds like a good plan to me.

The last update here was 2 years ago.

Ulf, did you get any further with this?

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

[Ulf Jasper]

Am 30.09.2023 um 19:12 (-0700) schrieb Stefan Kangas:

> The last update here was 2 years ago.
>
> Ulf, did you get any further with this?

Sorry, I lost track of this bug.  I also lost track of icalendar.el
itself.  I stopped using it some years ago.  I think it is time to step
back from maintaining icalendar.el.

Best,
ulf

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

[Stefan Kangas]

Ulf Jasper <ulf.jasper@web.de> writes:

> Am 30.09.2023 um 19:12 (-0700) schrieb Stefan Kangas:
>
>> The last update here was 2 years ago.
>>
>> Ulf, did you get any further with this?
>
> Sorry, I lost track of this bug.  I also lost track of icalendar.el
> itself.  I stopped using it some years ago.  I think it is time to step
> back from maintaining icalendar.el.

Noted.  Feel free to update the Maintainer header to reflect that
decision (or let me know, and I'll do it for you).

Thanks for all your work on icalendar.el over the years.

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

[Ulf Jasper]

Am 15.10.2023 um 07:28 (-0700) schrieb Stefan Kangas:
> Ulf Jasper <ulf.jasper@web.de> writes:
>
>> Am 30.09.2023 um 19:12 (-0700) schrieb Stefan Kangas:
>>
>>> The last update here was 2 years ago.
>>>
>>> Ulf, did you get any further with this?
>>
>> Sorry, I lost track of this bug.  I also lost track of icalendar.el
>> itself.  I stopped using it some years ago.  I think it is time to step
>> back from maintaining icalendar.el.
>
> Noted.  Feel free to update the Maintainer header to reflect that
> decision (or let me know, and I'll do it for you).

Removed myself from MAINTAINERS (for icalendar).  There is no maintainer
header in the el-files, BTW.

Best,
ulf

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

[Stefan Kangas]

Ulf Jasper <ulf.jasper@web.de> writes:

> Am 15.10.2023 um 07:28 (-0700) schrieb Stefan Kangas:
>> Ulf Jasper <ulf.jasper@web.de> writes:
>>
>>> Sorry, I lost track of this bug.  I also lost track of icalendar.el
>>> itself.  I stopped using it some years ago.  I think it is time to step
>>> back from maintaining icalendar.el.
>>
>> Noted.  Feel free to update the Maintainer header to reflect that
>> decision (or let me know, and I'll do it for you).
>
> Removed myself from MAINTAINERS (for icalendar).  There is no maintainer
> header in the el-files, BTW.

According to our conventions, the maintainer of a file without any
explicit "Maintainer" is whoever is marked as "Author".  I'm not
necessarily a fan of this convention, myself.  I'd prefer being
explicit.

However, this being the case, I think the correct thing to do in this
case is to add a header that points to emacs-devel.

So I did that.

Thanks.