Closed lelit closed 1 year ago
I tried to investigate and I think I am on something!
When org-jira-update-worklogs-from-org-clocks
has done its main job it calls org-jira-update-worklogs-for-issue to refresh the LOGBOOK
of the issue.
Down a couple of levels, there are calls to org-jira-date-to-org-clock, that for some reason explicitly calls org-jira-date-strip-letter-t
....
So what's happening is this:
the Jira worklogs contains an ISO8601 started
timestamp, say "2023-02-14T19:01:00.000+0100"
that's converted to a timestamp
(org-jira-date-strip-letter-t "2023-02-14T19:01:00.000+0100") => "2023-02-14 19:01:00+0100" (date-to-time "2023-02-14 19:01:00+0100") => (25578 49392)
and back to an org clock
(org-jira-time-stamp-to-org-clock '(25578 49392)) => "2023-02-14 mar 00:00"
where the time-of-the-day part is lost.
The problem apparently is in that call to org-jira-date-strip-letter-t
: omitting that we have
(date-to-time "2023-02-14T19:01:00.000+0100") => (25579 52316)
(org-jira-time-stamp-to-org-clock '(25579 52316)) => "2023-02-14 mar 19:01"
I have done some more tests, and can confirm that redefining the org-jira-date-to-org-clock
as
(defun org-jira-date-to-org-clock (date)
"Convert DATE into a time stamp and then into org-clock format.
Expects a date in format such as: 2017-02-26T00:08:00.000-0500."
(org-jira-time-stamp-to-org-clock (date-to-time date)))
the roundtrip works as expected, that is on Jira's worklogs I see the corrected timestamps, and at the end of org-jira-update-worklogs-from-org-clocks
the only modifications on the Org's logbook are the backported :id:
of each entry.
I'm using Emacs master, and accordingly to date-to-time documentation it is already able to parse an ISO-8601
timestamp: the oldest Emacs around me is Emacs 28, and this seems to work on that version as well.
Interesting - I remember writing the code to handle removal of the T
, but of course, in hindsight (and in commit messages) I can't figure out exactly "why" it was needed.
It was definitely solving something at one point, but seems to no longer be necessary...
Did you want to make a PR with this change?
in hindsight (and in commit messages) I can't figure out exactly "why" it was needed.
Maybe for some very old Emacs version?
Did you want to make a PR with this change?
Sure, I'll do that promptly.
All set, thanks!
I notice some differences between Jira worklog and Org logbook after repeated syncs.
A bit of context: until now (or more exactly, until I discovered
org-jira
some days ago) I used track the time I spent on various issues in a plain Org file. Since some of them are intertwined, I have a structure like the following:Experimenting with
org-jira
, I first fetched all my issues withorg-jira-get-issues
and then I copied thoseLOGBOOK
in the various issue collected in the resultingPROJ.org
.Doing a first
org-jira-update-worklogs-from-org-clocks
, theLOGBOOK
for PROJ-42 (inside the newPROJ.org
managed byorg-jira
) changed to the following:where you can see that all those intervals were shifted to the start of the day, although on the Jira instance I see the original hours (slightly edited for compactness):
If I now register some more work on that issue, for example:
then, re-executing
org-jira-update-worklogs-from-org-clocks
, I end up with the following inPROJ.org
:while on Jira I see this:
that is, the existing entries where updated (edited) loosing the correct time, while the new one for today carries the original time.
This is not a big problem of course, as I assume what matters for my customer is the actual sum of hours spent on a given issue and not when I did the actual work, but I wonder if this rings any bell to you, and if it can be rectified.
I'm still trying to figure out my own way of using
org-jira
, and I guess that, at least for a while, I will keep updating my original "plain" Org file, and now and then I will manually copy newCLOCK
lines from there to thePROJ.org
file eventually updating Jira. That would be simpler and less error prone if the time-of-the-day between the two matches, but all in allorg-jira
will surely take away the boringness of thru-the-web editing of Jira worklogs.Thanks in advance for any hint (and for
org-jira
:heart:).