* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling @ 2019-02-04 11:48 Thomas Plass 2019-02-12 18:57 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2019-02-04 11:48 UTC (permalink / raw) To: 34315 [-- 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 --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-04 11:48 bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling Thomas Plass @ 2019-02-12 18:57 ` Ulf Jasper 2019-02-15 17:17 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2019-02-12 18:57 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 Thanks for the patch. I'll have a look. Ulf ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-12 18:57 ` Ulf Jasper @ 2019-02-15 17:17 ` Ulf Jasper 2019-02-18 9:36 ` Thomas Plass 2020-08-10 11:48 ` Lars Ingebrigtsen 0 siblings, 2 replies; 51+ messages in thread From: Ulf Jasper @ 2019-02-15 17:17 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 Thomas, the patch looks good so far. Could you please provide some testcases so that I can add some unit tests? Best, ulf ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-15 17:17 ` Ulf Jasper @ 2019-02-18 9:36 ` Thomas Plass 2019-02-18 15:59 ` Eli Zaretskii 2020-08-10 11:48 ` Lars Ingebrigtsen 1 sibling, 1 reply; 51+ messages in thread From: Thomas Plass @ 2019-02-18 9:36 UTC (permalink / raw) To: Ulf Jasper; +Cc: 34315 [-- 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 --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-18 9:36 ` Thomas Plass @ 2019-02-18 15:59 ` Eli Zaretskii 2019-02-18 19:15 ` Thomas Plass 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2019-02-18 15:59 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 > 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-18 15:59 ` Eli Zaretskii @ 2019-02-18 19:15 ` Thomas Plass 2019-02-18 19:30 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2019-02-18 19:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-18 19:15 ` Thomas Plass @ 2019-02-18 19:30 ` Eli Zaretskii 2019-02-18 20:03 ` Thomas Plass 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2019-02-18 19:30 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 > 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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-18 19:30 ` Eli Zaretskii @ 2019-02-18 20:03 ` Thomas Plass 2019-02-18 20:16 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2019-02-18 20:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 34315 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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-18 20:03 ` Thomas Plass @ 2019-02-18 20:16 ` Eli Zaretskii 0 siblings, 0 replies; 51+ messages in thread From: Eli Zaretskii @ 2019-02-18 20:16 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 > 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2019-02-15 17:17 ` Ulf Jasper 2019-02-18 9:36 ` Thomas Plass @ 2020-08-10 11:48 ` Lars Ingebrigtsen 2020-08-10 16:08 ` Ulf Jasper 1 sibling, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-08-10 11:48 UTC (permalink / raw) To: Ulf Jasper; +Cc: 34315, Thomas Plass 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-10 11:48 ` Lars Ingebrigtsen @ 2020-08-10 16:08 ` Ulf Jasper 2020-08-10 16:45 ` Eli Zaretskii 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-08-10 16:08 UTC (permalink / raw) To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: 34315, Thomas Plass 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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-10 16:08 ` Ulf Jasper @ 2020-08-10 16:45 ` Eli Zaretskii 2020-08-10 17:04 ` Thomas Plass 0 siblings, 1 reply; 51+ messages in thread From: Eli Zaretskii @ 2020-08-10 16:45 UTC (permalink / raw) To: Ulf Jasper; +Cc: larsi, 34315, thunk2 > 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-10 16:45 ` Eli Zaretskii @ 2020-08-10 17:04 ` Thomas Plass 2020-08-11 11:01 ` Lars Ingebrigtsen 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-08-10 17:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-10 17:04 ` Thomas Plass @ 2020-08-11 11:01 ` Lars Ingebrigtsen 2020-08-11 15:14 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-08-11 11:01 UTC (permalink / raw) To: Thomas Plass; +Cc: Thomas Plass, 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-11 11:01 ` Lars Ingebrigtsen @ 2020-08-11 15:14 ` Ulf Jasper 2020-08-11 15:19 ` Lars Ingebrigtsen 2020-08-12 13:08 ` Thomas Plass 0 siblings, 2 replies; 51+ messages in thread From: Ulf Jasper @ 2020-08-11 15:14 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Thomas Plass 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! ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-11 15:14 ` Ulf Jasper @ 2020-08-11 15:19 ` Lars Ingebrigtsen 2020-08-11 15:45 ` Ulf Jasper 2020-08-12 13:08 ` Thomas Plass 1 sibling, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-08-11 15:19 UTC (permalink / raw) To: Ulf Jasper; +Cc: Thomas Plass, 34315, Thomas Plass 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-11 15:19 ` Lars Ingebrigtsen @ 2020-08-11 15:45 ` Ulf Jasper 0 siblings, 0 replies; 51+ messages in thread From: Ulf Jasper @ 2020-08-11 15:45 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Thomas Plass 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-11 15:14 ` Ulf Jasper 2020-08-11 15:19 ` Lars Ingebrigtsen @ 2020-08-12 13:08 ` Thomas Plass 2020-08-12 13:12 ` Lars Ingebrigtsen 1 sibling, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-08-12 13:08 UTC (permalink / raw) To: Ulf Jasper; +Cc: Lars Ingebrigtsen, 34315, 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 --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-12 13:08 ` Thomas Plass @ 2020-08-12 13:12 ` Lars Ingebrigtsen 2020-08-12 13:30 ` Thomas Plass 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-08-12 13:12 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-12 13:12 ` Lars Ingebrigtsen @ 2020-08-12 13:30 ` Thomas Plass 2020-08-12 15:06 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-08-12 13:30 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-12 13:30 ` Thomas Plass @ 2020-08-12 15:06 ` Ulf Jasper 2020-09-02 18:05 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-08-12 15:06 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-08-12 15:06 ` Ulf Jasper @ 2020-09-02 18:05 ` Ulf Jasper 2020-09-03 8:38 ` Thomas Plass 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-09-02 18:05 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-02 18:05 ` Ulf Jasper @ 2020-09-03 8:38 ` Thomas Plass 2020-09-03 14:28 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-09-03 8:38 UTC (permalink / raw) To: Ulf Jasper; +Cc: Lars Ingebrigtsen, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-03 8:38 ` Thomas Plass @ 2020-09-03 14:28 ` Ulf Jasper 2020-09-12 8:01 ` Thomas Plass 2020-09-29 10:05 ` Thomas Plass 0 siblings, 2 replies; 51+ messages in thread From: Ulf Jasper @ 2020-09-03 14:28 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-03 14:28 ` Ulf Jasper @ 2020-09-12 8:01 ` Thomas Plass 2020-09-12 8:11 ` Eli Zaretskii 2020-09-13 4:07 ` Richard Stallman 2020-09-29 10:05 ` Thomas Plass 1 sibling, 2 replies; 51+ messages in thread From: Thomas Plass @ 2020-09-12 8:01 UTC (permalink / raw) To: Ulf Jasper; +Cc: Lars Ingebrigtsen, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-12 8:01 ` Thomas Plass @ 2020-09-12 8:11 ` Eli Zaretskii 2020-09-13 4:07 ` Richard Stallman 1 sibling, 0 replies; 51+ messages in thread From: Eli Zaretskii @ 2020-09-12 8:11 UTC (permalink / raw) To: Thomas Plass; +Cc: larsi, 34315 > 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-12 8:01 ` Thomas Plass 2020-09-12 8:11 ` Eli Zaretskii @ 2020-09-13 4:07 ` Richard Stallman 1 sibling, 0 replies; 51+ messages in thread From: Richard Stallman @ 2020-09-13 4:07 UTC (permalink / raw) To: Thomas Plass; +Cc: larsi, 34315 [[[ 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) ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-03 14:28 ` Ulf Jasper 2020-09-12 8:01 ` Thomas Plass @ 2020-09-29 10:05 ` Thomas Plass 2020-10-01 1:45 ` Lars Ingebrigtsen 1 sibling, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-09-29 10:05 UTC (permalink / raw) To: Ulf Jasper; +Cc: Lars Ingebrigtsen, 34315 [-- 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 --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-09-29 10:05 ` Thomas Plass @ 2020-10-01 1:45 ` Lars Ingebrigtsen 2020-10-01 1:50 ` Lars Ingebrigtsen 2020-10-01 13:38 ` Thomas Plass 0 siblings, 2 replies; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-01 1:45 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315, Jan Tatarik [-- 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 ^ permalink raw reply related [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 1:45 ` Lars Ingebrigtsen @ 2020-10-01 1:50 ` Lars Ingebrigtsen 2020-10-01 13:38 ` Thomas Plass 1 sibling, 0 replies; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-01 1:50 UTC (permalink / raw) To: Thomas Plass; +Cc: 34315, Jan Tatarik 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 1:45 ` Lars Ingebrigtsen 2020-10-01 1:50 ` Lars Ingebrigtsen @ 2020-10-01 13:38 ` Thomas Plass 2020-10-01 16:19 ` Ulf Jasper 1 sibling, 1 reply; 51+ messages in thread From: Thomas Plass @ 2020-10-01 13:38 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 34315, Jan Tatarik 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)))) ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 13:38 ` Thomas Plass @ 2020-10-01 16:19 ` Ulf Jasper 2020-10-01 16:22 ` Lars Ingebrigtsen 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-10-01 16:19 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315, Jan Tatarik 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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 16:19 ` Ulf Jasper @ 2020-10-01 16:22 ` Lars Ingebrigtsen 2020-10-01 16:54 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-01 16:22 UTC (permalink / raw) To: Ulf Jasper; +Cc: Thomas Plass, 34315, Jan Tatarik 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 16:22 ` Lars Ingebrigtsen @ 2020-10-01 16:54 ` Ulf Jasper 2020-10-01 16:59 ` Lars Ingebrigtsen 2020-10-01 18:49 ` Thomas Plass 0 siblings, 2 replies; 51+ messages in thread From: Ulf Jasper @ 2020-10-01 16:54 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Jan Tatarik 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 16:54 ` Ulf Jasper @ 2020-10-01 16:59 ` Lars Ingebrigtsen 2020-10-01 18:40 ` Ulf Jasper 2020-10-01 18:49 ` Thomas Plass 1 sibling, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-01 16:59 UTC (permalink / raw) To: Ulf Jasper; +Cc: Thomas Plass, 34315, Jan Tatarik 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 16:59 ` Lars Ingebrigtsen @ 2020-10-01 18:40 ` Ulf Jasper 2020-10-01 18:47 ` Lars Ingebrigtsen 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-10-01 18:40 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Jan Tatarik 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 18:40 ` Ulf Jasper @ 2020-10-01 18:47 ` Lars Ingebrigtsen 2020-10-01 19:00 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-01 18:47 UTC (permalink / raw) To: Ulf Jasper; +Cc: Thomas Plass, 34315, Jan Tatarik 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 18:47 ` Lars Ingebrigtsen @ 2020-10-01 19:00 ` Ulf Jasper 0 siblings, 0 replies; 51+ messages in thread From: Ulf Jasper @ 2020-10-01 19:00 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Jan Tatarik 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 16:54 ` Ulf Jasper 2020-10-01 16:59 ` Lars Ingebrigtsen @ 2020-10-01 18:49 ` Thomas Plass 2020-10-01 18:53 ` Thomas Plass 2020-10-01 19:14 ` Ulf Jasper 1 sibling, 2 replies; 51+ messages in thread From: Thomas Plass @ 2020-10-01 18:49 UTC (permalink / raw) To: Ulf Jasper; +Cc: Lars Ingebrigtsen, Thomas Plass, Jan Tatarik, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 18:49 ` Thomas Plass @ 2020-10-01 18:53 ` Thomas Plass 2020-10-01 19:14 ` Ulf Jasper 1 sibling, 0 replies; 51+ messages in thread From: Thomas Plass @ 2020-10-01 18:53 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315, Jan Tatarik 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)))) ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 18:49 ` Thomas Plass 2020-10-01 18:53 ` Thomas Plass @ 2020-10-01 19:14 ` Ulf Jasper 2020-10-10 20:06 ` Lars Ingebrigtsen 1 sibling, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-10-01 19:14 UTC (permalink / raw) To: Thomas Plass; +Cc: Lars Ingebrigtsen, 34315, Jan Tatarik 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-01 19:14 ` Ulf Jasper @ 2020-10-10 20:06 ` Lars Ingebrigtsen 2020-10-22 15:50 ` Ulf Jasper 2023-10-01 2:12 ` Stefan Kangas 0 siblings, 2 replies; 51+ messages in thread From: Lars Ingebrigtsen @ 2020-10-10 20:06 UTC (permalink / raw) To: Ulf Jasper; +Cc: Thomas Plass, 34315, Jan Tatarik 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-10 20:06 ` Lars Ingebrigtsen @ 2020-10-22 15:50 ` Ulf Jasper 2021-05-11 14:10 ` Lars Ingebrigtsen 2023-10-01 2:12 ` Stefan Kangas 1 sibling, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2020-10-22 15:50 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Thomas Plass, 34315, Jan Tatarik 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-22 15:50 ` Ulf Jasper @ 2021-05-11 14:10 ` Lars Ingebrigtsen 2021-07-29 14:55 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Lars Ingebrigtsen @ 2021-05-11 14:10 UTC (permalink / raw) To: Ulf Jasper; +Cc: 34315, Jan Tatarik, Thomas Plass 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2021-05-11 14:10 ` Lars Ingebrigtsen @ 2021-07-29 14:55 ` Ulf Jasper 2021-07-30 11:37 ` Lars Ingebrigtsen 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2021-07-29 14:55 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 34315, Jan Tatarik, Thomas Plass 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2021-07-29 14:55 ` Ulf Jasper @ 2021-07-30 11:37 ` Lars Ingebrigtsen 0 siblings, 0 replies; 51+ messages in thread From: Lars Ingebrigtsen @ 2021-07-30 11:37 UTC (permalink / raw) To: Ulf Jasper; +Cc: 34315, Jan Tatarik, Thomas Plass 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2020-10-10 20:06 ` Lars Ingebrigtsen 2020-10-22 15:50 ` Ulf Jasper @ 2023-10-01 2:12 ` Stefan Kangas 2023-10-12 14:49 ` Ulf Jasper 1 sibling, 1 reply; 51+ messages in thread From: Stefan Kangas @ 2023-10-01 2:12 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Ulf Jasper, Eli Zaretskii, Thomas Plass, 34315, Jan Tatarik 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? ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2023-10-01 2:12 ` Stefan Kangas @ 2023-10-12 14:49 ` Ulf Jasper 2023-10-15 14:28 ` Stefan Kangas 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2023-10-12 14:49 UTC (permalink / raw) To: Stefan Kangas Cc: Lars Ingebrigtsen, Thomas Plass, Eli Zaretskii, Jan Tatarik, 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2023-10-12 14:49 ` Ulf Jasper @ 2023-10-15 14:28 ` Stefan Kangas 2023-10-19 14:11 ` Ulf Jasper 0 siblings, 1 reply; 51+ messages in thread From: Stefan Kangas @ 2023-10-15 14:28 UTC (permalink / raw) To: Ulf Jasper Cc: Lars Ingebrigtsen, Thomas Plass, Eli Zaretskii, Jan Tatarik, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2023-10-15 14:28 ` Stefan Kangas @ 2023-10-19 14:11 ` Ulf Jasper 2023-12-24 14:02 ` Stefan Kangas 0 siblings, 1 reply; 51+ messages in thread From: Ulf Jasper @ 2023-10-19 14:11 UTC (permalink / raw) To: Stefan Kangas Cc: Lars Ingebrigtsen, Thomas Plass, Eli Zaretskii, Jan Tatarik, 34315 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling 2023-10-19 14:11 ` Ulf Jasper @ 2023-12-24 14:02 ` Stefan Kangas 0 siblings, 0 replies; 51+ messages in thread From: Stefan Kangas @ 2023-12-24 14:02 UTC (permalink / raw) To: Ulf Jasper Cc: Lars Ingebrigtsen, Thomas Plass, Eli Zaretskii, Jan Tatarik, 34315 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2023-12-24 14:02 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-04 11:48 bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling Thomas Plass 2019-02-12 18:57 ` Ulf Jasper 2019-02-15 17:17 ` Ulf Jasper 2019-02-18 9:36 ` Thomas Plass 2019-02-18 15:59 ` Eli Zaretskii 2019-02-18 19:15 ` Thomas Plass 2019-02-18 19:30 ` Eli Zaretskii 2019-02-18 20:03 ` Thomas Plass 2019-02-18 20:16 ` Eli Zaretskii 2020-08-10 11:48 ` Lars Ingebrigtsen 2020-08-10 16:08 ` Ulf Jasper 2020-08-10 16:45 ` Eli Zaretskii 2020-08-10 17:04 ` Thomas Plass 2020-08-11 11:01 ` Lars Ingebrigtsen 2020-08-11 15:14 ` Ulf Jasper 2020-08-11 15:19 ` Lars Ingebrigtsen 2020-08-11 15:45 ` Ulf Jasper 2020-08-12 13:08 ` Thomas Plass 2020-08-12 13:12 ` Lars Ingebrigtsen 2020-08-12 13:30 ` Thomas Plass 2020-08-12 15:06 ` Ulf Jasper 2020-09-02 18:05 ` Ulf Jasper 2020-09-03 8:38 ` Thomas Plass 2020-09-03 14:28 ` Ulf Jasper 2020-09-12 8:01 ` Thomas Plass 2020-09-12 8:11 ` Eli Zaretskii 2020-09-13 4:07 ` Richard Stallman 2020-09-29 10:05 ` Thomas Plass 2020-10-01 1:45 ` Lars Ingebrigtsen 2020-10-01 1:50 ` Lars Ingebrigtsen 2020-10-01 13:38 ` Thomas Plass 2020-10-01 16:19 ` Ulf Jasper 2020-10-01 16:22 ` Lars Ingebrigtsen 2020-10-01 16:54 ` Ulf Jasper 2020-10-01 16:59 ` Lars Ingebrigtsen 2020-10-01 18:40 ` Ulf Jasper 2020-10-01 18:47 ` Lars Ingebrigtsen 2020-10-01 19:00 ` Ulf Jasper 2020-10-01 18:49 ` Thomas Plass 2020-10-01 18:53 ` Thomas Plass 2020-10-01 19:14 ` Ulf Jasper 2020-10-10 20:06 ` Lars Ingebrigtsen 2020-10-22 15:50 ` Ulf Jasper 2021-05-11 14:10 ` Lars Ingebrigtsen 2021-07-29 14:55 ` Ulf Jasper 2021-07-30 11:37 ` Lars Ingebrigtsen 2023-10-01 2:12 ` Stefan Kangas 2023-10-12 14:49 ` Ulf Jasper 2023-10-15 14:28 ` Stefan Kangas 2023-10-19 14:11 ` Ulf Jasper 2023-12-24 14:02 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).