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.

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

Alarm does not respect Time shift / Daylight saving time #447

Open
t-matze opened this issue Mar 26, 2023 · 11 comments
Open

Alarm does not respect Time shift / Daylight saving time #447

t-matze opened this issue Mar 26, 2023 · 11 comments

Comments

@t-matze
Copy link

t-matze commented Mar 26, 2023

Problem:

An alarm that is set before the night in which the time shift to daylight saving time occurs rings 1 hour too late the next morning.
This happened to me today. The alarm that I had set went off 1 hour late. The display showed me 9:30 a.m. (which was the present time), but I had set the alarm to 8:30 a.m. - and there was no alarm ringing at that time.
When I set the alarm, it informed me that it would be ringing in 7 hours from now. The night was 1 hour shorter because of the time shift - but the alarm rang 7 hours from the time I had set it.

Expected behavior:

An alarm should always ring at the time it is set to (absolute value).
"This alarm will ring in x hours" should only be an information, not the value that it calculates with.

Steps to reproduce:

  1. Set an alarm.
  2. Have a time shift occur between the setting of the alarm and the time it should ring. (Or simulate a time shift - I don't know if that would work also.)
  3. Sleep in because the alarm wakes you up 1 hour late.

System information:

Simple Clock Version 5.10.0 (up to date according to fdroid.org)
Samsung Galaxy A51
Android Version 13
Kernel Version 4.14.113-25357580

Do you need any further information?

@SmallAndSoft
Copy link

I can confirm that this issue exists. I had a daily alarm as 23:00 and it did not went off after switch to DST occurred on 26th of March 2023

@t-matze
Copy link
Author

t-matze commented Mar 27, 2023

Thank you for the confirmation.
Therefore, I would categorize it rather a bug report than a feature request.
To ask for an alarm you can trust on is not a "new feature", but the key function of the alarm.

@marissa999
Copy link

The already exists multiple versions of this issue.

Most importantly is the comment here:
#151 (comment)
"it doesnt matter what label is there... This app has been abandoned so it wont be fixed anytime soon."

I don't know enough about Android at all, so I probably won't try to look into the code myself and figure how it can be handled better. And I don't wanna be responsible for a missed alarm because of a bug of me 😅 I did quickly look into the Android API and it seems like the Android alarm manager doesn't handle it, which is really weird that Google didn't implement it? But well it is what it is...

Related issues:
#131

#266

#264

#151

@t-matze
Copy link
Author

t-matze commented Mar 28, 2023

Thank you, marissa999 for pointing us to the multiple earlier bug reports and the most important message from tibbi. So sad that he doesn't care to fix this issue.

I still don't understand how this app can be called abandoned if he keeps putting out new versions:

Releases 36
5.10.1
Latest
3 days ago

@tibbi could you please clarify whether or not you are still updating the simple clock app? And if there is a timeline in which you plan to fix this long-known bug?

This will help me and others that need an alarm that can be trusted to decide whether to stick with your nice app or look for an alternative.

Thank you.

@tibbi
Copy link
Contributor

tibbi commented Mar 28, 2023

the app is updated, but daylight savings arent really high priority. It is really difficult to get it right and it isnt causing issues to many people.

@inson1
Copy link

inson1 commented Oct 18, 2023

@tibbi I think its bug and not feature request

@Beanow
Copy link

Beanow commented Oct 29, 2023

Same here. Back with a report on the next DST shift.

I set the alarm yesterday (before DST change) for 9am, at 3am the DST shift occurred, the alarm went off at 8am.
Toggling the alarm on and off at 8:15am, it gave me the "45 minutes" toast message.


It is really difficult to get it right

Yes. Yes it is. The advice should really be updated. "Don't roll your own crypto, nor time library."

it isnt causing issues to many people.

It seems to be affecting plenty of people though.
There are several regions that observe DST https://en.wikipedia.org/wiki/Daylight_saving_time
And this isn't the first report:

That said, I understand the app essentially has a sole maintainer. So I don't mean this as criticism.


For an issue like this, I strongly recommend reproducing the issue in automated tests.

Especially DST issues that happen twice a year, but even common scenarios like "set an alarm for next morning" is very slow to test manually as it literally takes between several hours to half a year to test manually.

While during development you ideally want to know if your changes work in a few seconds.
So tests are the only way I've found lets you solve time-bugs in a reasonable amount of time as a dev.

Right now, it seems like there are no such tests in place. And I think it'll be very unlikely for a contributor to add it.
Adding tests for the first time to a years-old "brownfield" project involves a lot of decisions on tools, frameworks and architecture. Besides taking more time than the typical contributor is willing to spend, they often don't have enough context to do so.

In other words, whether it's figuring out DST manually, or introducing testing tools. I think both are a big effort and will probably come down to @tibbi to implement, or not 🤕

@mgorny
Copy link

mgorny commented Oct 29, 2023

For the record, the "real" time when the alarm's going to go off shows both on the lock screen and on the widget, i.e. when I set it to 5:30 yesterday, the widget/lock screen showed 4:30.

@ColonelThirtyTwo
Copy link

Java 8 has built in classes for proper timezone conversions.

import java.time.ZonedDateTime;
import java.time.ZoneId;

public class Main
{
    public static void main(String[] args) {
        ZoneId zoneId = ZoneId.of("America/New_York");
        ZonedDateTime preDst = ZonedDateTime.of(2024, 3, 9, 7, 0, 0, 0, zoneId);
        ZonedDateTime postDst = ZonedDateTime.of(2024, 3, 10, 7, 0, 0, 0, zoneId);
        System.out.printf("preDst: %d, postDst: %d", preDst.toEpochSecond(), postDst.toEpochSecond());
    }
}
preDst: 1709985600, postDst: 1710068400

preDist is "Sat Mar 09 2024 07:00:00 GMT-0500 (Eastern Standard Time)", postDST is "Sun Mar 10 2024 07:00:00 GMT-0400 (Eastern Daylight Time)" - i.e. it works correctly across DST shifts.

The fact that this isn't labeled as a bug is not a good look for the app, and a large gotcha for anyone relying on it. If my 7:00 alarm goes off at 8:00, that's the clock app not working, not a "missing feature".

@inson1
Copy link

inson1 commented Mar 11, 2024

@ColonelThirtyTwo SMT apps were sold to ad company. SimpleMobileTools/General-Discussion#241
Fork is here https://github.com/FossifyOrg

@ColonelThirtyTwo
Copy link

ColonelThirtyTwo commented Mar 12, 2024

@ColonelThirtyTwo SMT apps were sold to ad company. SimpleMobileTools/General-Discussion#241 Fork is here https://github.com/FossifyOrg

RIP thanks for letting me know

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

No branches or pull requests

8 participants