Skip to content

Resolves issue#827, where timeUntilAlarm wasn't working as Expected #833

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.

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Gaurav-Kushwaha-1225
Copy link
Contributor

@Gaurav-Kushwaha-1225 Gaurav-Kushwaha-1225 commented Apr 24, 2025

Description

Now, the alarm scheduling logic incorporates the alarmDate parameter into the timeUntilAlarm function for the calculation of a non-repeating alarm that's scheduled after some days.

Also, you can refer to this small discussion #gsoc-ultimate-alarm-clock > @ 💬, regarding the Repeat and Rings On feature, where it was proposed to disable the Rings On when Repeat is enabled, or vice versa.

Proposed Changes

  • Added alarmDate Parameter: The timeUntilAlarm function now accepts an additional alarmDate parameter to handle date-based alarm scheduling.

  • Controller Updates: Now, if Rings On is enabled or selectedDate != DateTime.now(), then make the Repeat as Never or repeatDays = [false, false, false, false, false, false, false]. Or, vice versa.

Fixes #827

Screenshots

In the video below, the calculation for Rings in __ is now accurate for alarms set on a specific date. And, selecting both a specific date alarm and a repeat alarm is not possible, since enabling one will disable the other.

Record_2025-04-25-01-01-03.mp4

Checklist

  • Tests have been added or updated to cover the changes
  • Documentation has been updated to reflect the changes
  • Code follows the established coding style guidelines
  • All tests are passing

@Gaurav-Kushwaha-1225
Copy link
Contributor Author

Gaurav-Kushwaha-1225 commented Apr 24, 2025

In the latest commit, I also resolved a problem in calculating the rings in value for an alarm, set for repeat on a day which is the same as today.

Like in the video below, today is Friday, and 'Rings in' was giving "Rings in No upcoming alarms", instead of "Rings in 6 days", when set the repeating day as Friday itself.

Video from the latest commit in the main branch Video from the latest commit on this PR
Record_2025-04-25-01-46-26.mp4
Record_2025-04-25-01-44-09.mp4

@mahendra-918
Copy link
Collaborator

Hii @Gaurav-Kushwaha-1225 take a look at PR(#830) which has good UI/UX and solves the ringson issue , rings in duration

@Gaurav-Kushwaha-1225
Copy link
Contributor Author

Hi @mahendra-918, I saw your PR (#830) — it looks good!

However, I noticed that you've made some significant changes to the UI as well. The original issue #827 you addressed was specifically about the bug in the timeUntilAlarm method that calculates the Rings in __ value.

If you are planning to implement any additional ideas, it would be better to discuss them first in the Zulip discussion group to get some feedback from mentors and community members.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: The Calculation of timeUntilAlarm is **Not** working as expected when comes to days
2 participants