From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dale Sedivec Subject: Re: Bug: clocktable interprets tstart/tend incorrectly, maybe? [9.0.9 (9.0.9-636-gd39ccc-elpaplus @ /tmp/emacs/.emacs.d/elpa/org-plus-contrib-20170709/)] Date: Sat, 15 Jul 2017 01:15:55 -0500 Message-ID: References: <87tw2kwtut.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="001a114d9ad6a6f26b0554551bb2" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dWGNd-0005sr-Qg for emacs-orgmode@gnu.org; Sat, 15 Jul 2017 02:16:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dWGNb-0000q3-Fe for emacs-orgmode@gnu.org; Sat, 15 Jul 2017 02:16:41 -0400 Received: from mail-yw0-x234.google.com ([2607:f8b0:4002:c05::234]:36134) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dWGNb-0000pe-7d for emacs-orgmode@gnu.org; Sat, 15 Jul 2017 02:16:39 -0400 Received: by mail-yw0-x234.google.com with SMTP id a12so32501055ywh.3 for ; Fri, 14 Jul 2017 23:16:37 -0700 (PDT) In-Reply-To: <87tw2kwtut.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org --001a114d9ad6a6f26b0554551bb2 Content-Type: multipart/alternative; boundary="001a114d9ad6a6f2660554551bb0" --001a114d9ad6a6f2660554551bb0 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 3:59 AM, Nicolas Goaziou wrote: > Hello, > > Dale Sedivec writes: > [...] > > I notice that as of 112c5ba479d, org-clocktable-steps parses :tstart and > > :tend with the ZONE argument to org-parse-time-string as T. I think this > > is causing org-parse-time-string to parse these user-entered dates as UTC > > rather than the user's local time as I would have expected. Changing > > org-clocktable-steps from doing (org-parse-time-string ts nil t) > > to (org-parse-time-string ts nil nil), and then the same for te as well, > > seems to fix this problem. > > Fixed. Thank you for the report and the analysis. > Thank you as always Nicolas! You fixed the time zone for :tstart in 60eda8e4ec4. However, I think the parsing of :tend (locally bound as te) eight lines below that needs the same fix. Diff attached this time, just to demonstrate what I'm talking about. (Sorry I don't send more patches, but I have not updated my copyright assignment to reflect my new employer.) Steps to reproduce: * Start Emacs 25.1 in an empty $HOME with TZ=America/Chicago * Install org-mode HEAD * Insert the following into an org-mode buffer and update the dblock: ~~~~~~ * Test :LOGBOOK: CLOCK: [2017-07-15 Sat 00:01]--[2017-07-15 Sat 01:01] => 1:00 :END: #+BEGIN: clocktable :maxlevel 2 :scope subtree :tstart "<2017-07-09 Sun>" :tend "<2017-07-16 Sun>" :step day #+END: ~~~~~~ Expected result: The last step in the clock table for 2017-07-15 shows 1 hour Actual result: The last step in the clock table for 2017-07-15 shows 0 hours Thanks again, Dale --001a114d9ad6a6f2660554551bb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 3:59 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr= > wrote:
Hello,

Dale Sedivec <dale@codefu.org>= writes:
[...]=C2=A0
> I notice that as of 112c5ba479d, org-clocktable-steps parses :tstart a= nd
> :tend with the ZONE argument to org-parse-time-string as T.=C2=A0 I th= ink this
> is causing org-parse-time-string to parse these user-entered dates as = UTC
> rather than the user's local time as I would have expected.=C2=A0 = Changing
> org-clocktable-steps from doing (org-parse-time-string ts nil t)
> to (org-parse-time-string ts nil nil), and then the same for te as wel= l,
> seems to fix this problem.

Fixed. Thank you for the report and the analysis.

Thank you as always Nicolas!=C2=A0 You fixed the tim= e zone for :tstart in 60eda8e4ec4.=C2=A0 However, I think the parsing of :t= end (locally bound as te) eight lines below that needs the same fix.=C2=A0 = Diff attached this time, just to demonstrate what I'm talking about. = =C2=A0(Sorry I don't send more patches, but I have not updated my copyr= ight assignment to reflect my new employer.)

Steps= to reproduce:

* Start Emacs 25.1 in an empty $HOM= E with TZ=3DAmerica/Chicago

* Install org-mode HEA= D

* Insert the following into an org-mode buffer a= nd update the dblock:

~~~~~~
* Test=
=C2=A0 :LOGBOOK:
=C2=A0 CLOCK: [2017-07-15 Sat 00:01]-= -[2017-07-15 Sat 01:01] =3D> =C2=A01:00
=C2=A0 :END:
#+BEGIN: clocktable :maxlevel 2 :scope subtree :tstart "<2017-07-0= 9 Sun>" :tend "<2017-07-16 Sun>" :step day
#+END:
~~~~~~

Expected result: T= he last step in the clock table for 2017-07-15 shows 1 hour

<= /div>
Actual result: The last step in the clock table for 2017-07-15 sh= ows 0 hours

Thanks again,
Dale
--001a114d9ad6a6f2660554551bb0-- --001a114d9ad6a6f26b0554551bb2 Content-Type: text/plain; charset="US-ASCII"; name="org-clocktable-end-fix.diff" Content-Disposition: attachment; filename="org-clocktable-end-fix.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j54wedjz0 ZGlmZiAtLWdpdCBhL2xpc3Avb3JnLWNsb2NrLmVsIGIvbGlzcC9vcmctY2xvY2suZWwKaW5kZXgg OGUwNGFlYzJkZC4uNDE2NGM5MmFiYSAxMDA2NDQKLS0tIGEvbGlzcC9vcmctY2xvY2suZWwKKysr IGIvbGlzcC9vcmctY2xvY2suZWwKQEAgLTI3MTAsOCArMjcxMCw3IEBAIExFVkVMIGlzIGFuIGlu dGVnZXIuICBJbmRlbnQgYnkgdHdvIHNwYWNlcyBwZXIgbGV2ZWwgYWJvdmUgMS4iCiAgICAgICAo cGNhc2UtbGV0ICgoYCgsbW9udGggLGRheSAseWVhcikgKGNhbGVuZGFyLWdyZWdvcmlhbi1mcm9t LWFic29sdXRlIHRlKSkpCiAJKHNldHEgdGUgKGZsb2F0LXRpbWUgKGVuY29kZS10aW1lIDAgMCAw IGRheSBtb250aCB5ZWFyKSkpKSkKICAgICAgKHRlCi0gICAgICAoc2V0cSB0ZSAoZmxvYXQtdGlt ZQotCQkoYXBwbHkgIydlbmNvZGUtdGltZSAob3JnLXBhcnNlLXRpbWUtc3RyaW5nIHRlIG5pbCB0 KSkpKSkpCisgICAgICAoc2V0cSB0ZSAoZmxvYXQtdGltZSAoYXBwbHkgIydlbmNvZGUtdGltZSAo b3JnLXBhcnNlLXRpbWUtc3RyaW5nIHRlKSkpKSkpCiAgICAgKHNldHEgdHNiCiAJICAoaWYgKGVx IHN0ZXAwICd3ZWVrKQogCSAgICAgICgtIHRzICgqIDg2NDAwICgtIChudGggNiAoZGVjb2RlLXRp bWUgKHNlY29uZHMtdG8tdGltZSB0cykpKSB3cykpKQo= --001a114d9ad6a6f26b0554551bb2--