Removing fuzzy NOW date

[jaesivsm]

While rebasing #597, I observed something strange, Date.now(), Date('now'), Date.parse('now') and all the variations around that pattern returns a fuzzy date. Which brings me to the following two points :

• NOW ain't fuzzy x) it's just now, so it's conceptually weird to mark it as fuzzy
• Fuzzy values persisting as so even through writing in an xml file is weird. For example if I say due date is NOW and comes back tomorrow, it won't be "Yesterday" then, it'll still be NOW.

I open that PR to discuss the opportunity and implementation of changing that behaviour and make all NOW return straight forward datetime.now() in a GTG.core.dates.Date instance.

(That PR is based on #597 and includes code from that PR, I'll clean the whole stuff before merging if it's decided to be so).

[diegogangl]

Now is used to mark something as urgent, so it flies up to the top when sorting (at least that's the idea). This is worth thinking about though. Since now doesn't always end up at the top. If we use the current date instead of a fuzzy now, tasks would go into overdue and move to the top. Whereas using "fuzzy now", means something like "ASAP".

(it's probably easier to see in an image)

I wonder if we could simplify our fuzzy-ness. Do we really now and soon? (Also I summon @nekohayo to weigh in on this)

[nekohayo]

Yeah I do use "now" and "soon" extensively, basically for pinning some tasks as first and second priorities without being specific-deadline-sensitive. I suppose a decent amount of users make use of that too. I would like to retain the ability to do so, I don't see what we gain from removing those statuses? At first when I looked at the description above I thought it was about fixing some odd backend distinction somewhere, but if you're saying that the status is pointless to have at all, I'd say I disagree with that; "now" always remains "now" without being attached to a particular date, being top-of-the-line without being more urgent than overdue date-specific tasks...

[jaesivsm]

Well this has been written a while ago so I'm speaking from memory alone but the idea isn't to remove either display of the now or natural language parsing for auto setting the due date but to actually remove the fact that, internally, when parsing a now, now is registered.
It's a behavior which is fine with soon or someday since it's stays in a near future indefinitely but kinda of bothering me in the case of now. Setting a date to now and leaving it at that, it'll still be now the next day.

So yeah, PR isn't done but it's mainly to discuss the idea of:

• natural language parsing casting to a precise date (now get's actual date of when it was typed)
• displaying of all date in certain context to be fuzzy / relative => (all date +/- 1 hour of datetime.now() are displayed as now)

It'd also be the occasion of moving the entire logic of date parsing out of the date module.

[diegogangl]

Coming back to this. As far as I understand, now isn't supposed to be actually now but rather something like ASAP, or Urgent.

displaying of all date in certain context to be fuzzy / relative => (all date +/- 1 hour of datetime.now() are displayed as now)

Not too sure about this, since we don't do hours at all in due/start dates. Also if you are doing pomodoro or other time-block systems, +/- 1hr is about three different blocks (possibly assigned to different tasks).

[diegogangl]

@jaesivsm Any new plans regarding this PR or should we close it?

[jaesivsm]

Not too sure about this, since we don't do hours at all in due/start dates. Also if you are doing pomodoro or other time-block systems, +/- 1hr is about three different blocks (possibly assigned to different tasks).

The size of the blocks is totally up to discussion, I was merely proposing this.

@jaesivsm Any new plans regarding this PR or should we close it?

I'm more than willing to work on it, but does the main principle of the PR has any appeal to anyone ?

To reformulate I would say my idea was to :

• Have precise dates everywhere, dropping the fuzzy ones
• Have fuzzy display where needed in the UI
• It would not change AT ALL the way the UI behave, selecting "now" would still pin the issue between the ones already behind and the ones that are to comes
• It would allow a "soon" to be come a "in a week" after some time

[diegogangl]

Have precise dates everywhere, dropping the fuzzy ones
Have fuzzy display where needed in the UI
It would not change AT ALL the way the UI behave, selecting "now" would still pin the issue between the ones already behind and the ones that are to comes
It would allow a "soon" to be come a "in a week" after some time

This does sounds interesting, I mean we could drop the entire date class altogether, but what about "someday"?

[jaesivsm]

we could drop the entire date class altogether

Yes and now, the date class provides nice shortcut for date localization and displaying (also parsing). But they could be just method regrouped in a module which always returns datetime.datetime instances.

what about "someday"?

someday and soon would be just like now, they would just be displayed string in specific contexts.

[diegogangl]

someday and soon would be just like now, they would just be displayed string in specific contexts

But how do you store them?

[nekohayo]

It would not change AT ALL the way the UI behave, selecting "now" would still pin the issue between the ones already behind and the ones that are to comes

…Oh. I think I finally see why you might want to propose this whole idea, now.
It seems to me that this is for two reasons:

• From a UI standpoint, could it be that you are conceptually speaking to the same idea I subconsciously had in Starring / pinning daily goal tasks for the day (or week), and integration with "one thing" GNOME Shell extensions #948 ?
  (I had been thinking about it on-and-off for years, but it's only last year that I finally decided to write it down into an official feature request idea because I came to think that "there has to be a better way"); if you do something like that, and/or keep a way for the current UI workflow to work, then I don't really have an objection...
• From a backend/format standpoint, you "just" want to decouple that concept from the duedate data structure, for some reason. That's the part that Diego is wondering about.

Those two concepts combined is the only reason I can imagine why you would want to go through this trouble... to allow "temporarily pinning" (or reversibly pinning) to the top, without sacrificing the exact duedate value once the task "unpins" itself (or the user unpins it). Is that what you wanted to achieve? In that case, I suspect both me and @diegogangl can picture ourselves in what you are aiming to accomplish here. I am sorry that it has taken me so long to come back to look at tickets and MRs (now that the big refactoring cycle has been completed). It might help to clarify the title of this PR to not sound like it's just about removing functionality.

I'm no backend/format expert, but in that case I guess this could be accomplished with another "pinned-until" property (or something like that) which allows pinning a task to the equivalent of "now", forever or up until a certain date? Others will certainly have more precise thoughts than me on the matter of implementation.

[diegogangl]

IIRC @jaesivsm was referring to a backend POV. The UX would be unchanged because "now" would turn to "yesterday" and still show up high in the list of tasks when sorted by due date.

Removing 0.7 milestone for this since it's going to take some more consideration (and a rebase). Also, we've had more than enough refactoring for one release :)