Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Calendar date picker date mismatch #667

Closed
kidorion opened this issue Jan 16, 2021 · 8 comments
Closed

Calendar date picker date mismatch #667

kidorion opened this issue Jan 16, 2021 · 8 comments
Labels
duplicate

Comments

@kidorion
Copy link

The date picked in graphical UI calendar doesn't match the date applied to command line.
My guess is a locale problem. My locale is Sydney, Australia = UTC+10 or UTC+11 during summer.
I'm using Linux Mint Debian 10.2 buster, Cinnamon desktop 4.6.7.
Goal: try and make an entry for yesterday Friday 2021-01-15 09:00-15:00
Thanks..
Steps to reproduce are:

  1. Add activity
  2. Enter start time as 09:00
  3. Select started date in calendar graphical UI as 2021-01-15
  4. Date in command line is 2021-01-14
    See image:
    image

Also browsing past entries using the Graphical UI show similar out-by-one-day errors.
@GeraldJansen
Copy link
Contributor

Hamster just works with local times so I don't believe your location is the issue. More likely this is a duplicate of previously reported issues being worked on in #630. (Hopefully work on this very important issue will be resumed soon!)

@ederag
Copy link
Collaborator

ederag commented Jan 16, 2021

There has been a fix pending for 8 months and a half: #597 (comment)

lynxis added a commit to lynxis/hamster that referenced this issue Feb 16, 2021
@lynxis
hamser/client: edit_activty: don't touch self.date on date changes
acbd8dc 
The fact is recalculated already in on_start_date_change(). By calling the setter of
self.date the fact would be change a second time. The start_date was then wrong by
the delta. E.g. edit a complete fact (start and end must be set). Click on the start date and choose 2 days into the future, the command line shows now 4 days into the future.

Fixes: projecthamster#667
lynxis added a commit to lynxis/hamster that referenced this issue Feb 16, 2021
@lynxis
client: edit_activty: don't touch self.date on date changes
67871b9 
The fact is recalculated already in on_start_date_change().
By calling the setter of self.date the fact would be change
a second time. The start_date was then wrong by the delta.
E.g. edit a complete fact (start and end must be set). Click
on the start date and choose 2 days into the future,
the command line shows now 4 days into the future.

Fixes: projecthamster#667
@lynxis lynxis mentioned this issue Feb 16, 2021
Closed
@Pops34
Copy link

Pops34 commented Feb 17, 2021

same problem
It's the 17th, I want to add an activity from the previous day, the 16th, I go back to Tuesday the 16th, the software displays Monday the 15th (inconsistent date), and when I want to correct the date by adding an activity, there is a difference between the selected date and the saved command line.
bug1
bug2

@ederag
Copy link
Collaborator

ederag commented Feb 17, 2021

A fix has been pending for 9 months and a half: #597 (comment)

@GeraldJansen
Copy link
Contributor

@ederag That fix has been rejected by current maintainers and closed for several months now. If you are still interested in making a positive contribution to the project please consider making a new minimal pull request based on current master. Otherwise please do us all a favour and move on.

@ederag
Copy link
Collaborator

ederag commented Feb 17, 2021

do us all a favour and move on

Interesting tone.
Where is your aspiration to democracy (I just give information to this community) ?
Or was it just about power ?
Do you realize that the current maintainers, by letting this issue rot, and letting duplicates pile up,
give a wrong impression of our quality ?
People notice only the interface, which was on its way to become as robust as the infrastructure.
But I gave up on that, since the new team clearly has different views.

If you are still interested in making a positive contribution to the project please consider making a new minimal pull request based on current master.

Why would I take that time ? The previous one was discarded because they play the boss.
The fix is available for anyone to test, it's easy.

That fix has been rejected by current maintainers and closed for several months now.

They overlooked some aspects, as explained in #630 (comment),
and at least one clearly understood the rationale: #630 (comment).

@matthijskooijman
Copy link
Member

I do not think discussion on the merits of your PR should happen here, so I added a comment there to further clarify why I closed it, to prevent further clouding discussion here.

However, I do believe that @GeraldJansen makes a good point. @ederag, if you're interested in adding information to duplicate issues, I suggest you link to a relevant existing open issue or pullrequest, rather than your own comment on your own PR. Right now, it sounds to me like you're not trying to contribute with information, but are only commenting out of spite. Your last comment, and most of your recent comments would not qualify as constructive to me, so I'd second @GeraldJansen's suggestion to make positive contributions (like this comment), or none at all.

Getting back to the actual subject of this issue: @kidorion, @Pops34, thanks for taking the time to report this issue. I suspect it is the same issue as reported in #590, so I'm going to close this issue as a duplicate of that. We have been aware of that issue for quite a while, but a proper fix turned out a bit more involved that one would hope, and there are a few different approaches, but nothing merged yet. Work on this issue seems to have died down a bit in the last months, for me personally due to other priorities, but I do think this is an important issue to tackle sooner rather than later.

@ederag
Copy link
Collaborator

ederag commented Feb 17, 2021

Your last comment, and most of your recent comments would not qualify as constructive to me

Yet other comments mislead people into not testing it.
I deem constructive to give the community another chance to fix the issue.
Sorry you feel otherwise.

@ederag ederag mentioned this issue Mar 12, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
duplicate
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

hamster/client: edit_activity: don't touch self.date on date changes lynxis/hamster
5 participants
@matthijskooijman @ederag @GeraldJansen @kidorion @Pops34