Etar-Group
editing an all-day event causes it to be moved back by one day
(this happened with a loval calendar, though that's probably unrelated)
- create an event, check the box for "all day" to be on
- save the event
- tap event
- edit
- save
the event will be moved to the previous day.
I think this is a duplicate of #1164.
it is not. that issue is for any event, this issue only applies to all-day events.
although both seem to step from the same design decision, namely that there is some about of date conversion happening when the event is edited, and it seems this conversion can go wrong in a number of ways.
I can corroborate this issue. If you edit an event marked for the whole day, saving will push back the ending date by one day.
I am seeing this issue now as well. In my case, it is causing the start date of an all-day event to shift back by one day every time I edit the event. If I don't remember to change the start date back to the actual applicable date before saving, it moves the event back a day. Can repeat and literally cause an event to walk backwards on the calendar. For a calendar app, this is about as critical of a bug as there can be, so this needs to be fixed ASAP.
Edit: This bug is not affected by changing the "Use home timezone" setting, as referenced in #1265. Regardless of whether that setting is off or on, editing an existing all-day event causes the editor to immediately jump back one day on the start date.
Would be cool if you could test the PR#1405(apk is here: https://github.com/Etar-Group/Etar-Calendar/actions/runs/5638046915) maybe it fixes the problem. I can not reproduce it on my phone unfortunately.
Would be cool if you could test the PR#1405(apk is here: https://github.com/Etar-Group/Etar-Calendar/actions/runs/5638046915) maybe it fixes the problem. I can not reproduce it on my phone unfortunately.
I'll try to give this a run later today and report back!
Would be cool if you could test the PR#1405(apk is here: https://github.com/Etar-Group/Etar-Calendar/actions/runs/5638046915) maybe it fixes the problem. I can not reproduce it on my phone unfortunately.
I'll try to give this a run later today and report back!
This specific APK build does resolve the problem with editing an all-day event. But when you're done editing the event and returning to the day-view, it jumps to the previous day. Was also seeing this with the editing bug in place, so it's likely a separate bug, but probably related to bad date/time calculations in the code that sets the current view or such.
This comment may mirror others' experiences, but I will add my own as a data point.
Often I am quickly "save the date" when learning about an event that I must remember, so I will open etar and add the date to my calendar as an all-day event since I do not know what exact time will be. Later I may learn of a time and then go back to edit the event to match. This worked great for years in etar but after some update (maybe in the previous year? it has been broken a long time) the edit of existing entry goes wild.
It's been really bad for me to be told a specific time and enter what I think is just changing from all-day to not-all-day at a specific time, but the day is completely wrong. This all used to work great but has been broken so long that I've given up using anything but all-day and I will list in the title of the event the times I need to remember.
With this APK above, when creating an event all-day, then I go back to the event and edit changing to not-all-day, the event is now on two days: day and day+1. This ignores the default event duration I have configured of 2 hours. Aside, it is also not obvious anymore how to prevent reminders from being created, which is a breaking change. Something was fixed, and something else is broken, the result is unfortunately not usable. Is there another bug report I should track?
Could one of the persons having the issue with the PR#1405 apk please give as complete as possible description of their environment so that we/I can try to match it to reproduce, and in particular:
- what is your system-wide timezone?
- is etar's "use home timezone" option activated?` if it is, what is the configured home timezone in etar?
With this APK above, when creating an event all-day, then I go back to the event and edit changing to not-all-day, the event is now on two days: day and day+1.
This ignores the default event duration I have configured of 2 hours.
I feel this is a different issue, maybe even an enhancement/feature request. Please file it separately and @-mention me in it so that I get notified.
Already, I can say: an all-day event is "by definition" from midnight to midnight (let's say it is some UI sugar for a midnight-to-midnight event although that is not 100% correct, and a bit of an oversimplification due to differences with timezone treatment...), and that is exactly what you get when you deactivate the "all day" slider: midnight to midnight in your local (system or home, depending on your settings) timezone.
I'm not sure what else you'd expect. It seems you expect the duration to be 2 hours because that's the default duration that you set in Etar's "General Settings / Default event duration". Fair enough, that makes some sense and could be implemented. But at what time should it start? Do you want it to just start at midnight and be the default duration? If not, how to determine the time it should start at?
With this APK above, when creating an event all-day, then I go back to the event and edit changing to not-all-day, the event is now on two days: day and day+1.
This ignores the default event duration I have configured of 2 hours.
I feel this is a different issue, maybe even an enhancement/feature request. Please file it separately and @-mention me in it so that I get notified.
Filed as #1457 and #1458.
Already, I can say: an all-day event is "by definition" from midnight to midnight (let's say it is some UI sugar for a midnight-to-midnight event although that is not 100% correct, and a bit of an oversimplification due to differences with timezone treatment...), and that is exactly what you get when you deactivate the "all day" slider: midnight to midnight in your local (system or home, depending on your settings) timezone.
I'm not sure what else you'd expect. It seems you expect the duration to be 2 hours because that's the default duration that you set in Etar's "General Settings / Default event duration". Fair enough, that makes some sense and could be implemented. But at what time should it start? Do you want it to just start at midnight and be the default duration? If not, how to determine the time it should start at?
We are over-thinking it.
The workflow does not care what time of day to guess what the user wants, it just needs to be on the same calendar day so that my actions as a user are simple in the simple case: I adjust the time. That's it. If I have to go poking around to figure what day and beginning or ending then this is not the normal use case and if so I would want an option to stop etar from nudging the ending date and time beyond what I am expecting, so that I can easily adjust. I as the user know some or all of what I am entering data for and I just want a consistent experience that doesn't make me tap and click and have to negotiate with the user interface unnecessarily to express what I already know.
Aside: Thank you very much, genuinely. I have too-little patience for bad workflow and user interface problems and no desire to write the code myself to do the hard work making an improvement.
My 2 cents here...
I'm not sure what else you'd expect. It seems you expect the duration to be 2 hours because that's the default duration that you set in Etar's "General Settings / Default event duration". Fair enough, that makes some sense and could be implemented. But at what time should it start? Do you want it to just start at midnight and be the default duration? If not, how to determine the time it should start at?
I think the proper way would be to start at midnight (since, as you said, Etar cannot know the proper start hour) and use the default event duration. Thus, the user will only have to adjust the start hour (that's fair) and, if needed, the event duration.
Currently, since the previoussly-full-day event goes from midnight to midnight, we have three changes to make (if we follow what I believe is the most logical path) :
- changing the start hour -> event goes from day/start hour to day+1/start hour (still 24 hours long)
- change the end hour -> event goes from day/start hour to day+1/end hour
- change the end day -> event goes from day/start hour to day/end hour
(step 2 and 3 may be inverted with the same result).
This is a little bit complex, whereas if making a full-day event into a « proper » not-full-day-event-with-default-duration, in most case the user will only have to change the start hour.
We are over-thinking it.
The workflow does not care what time of day to guess what the user wants, it just needs to be on the same calendar day so that my actions as a user are simple in the simple case: I adjust the time. That's it. If I have to go poking around to figure what day and beginning or ending then this is not the normal use case and if so I would want an option to stop etar from nudging the ending date and time beyond what I am expecting, so that I can easily adjust. I as the user know some or all of what I am entering data for and I just want a consistent experience that doesn't make me tap and click and have to negotiate with the user interface unnecessarily to express what I already know.
Completely agree.
