-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
iOs crash with date nil with zoned schedule #1950
Comments
@MaikuB "dateComponents must not be nil" ,I saw an old issue about this but I don't think it is related |
my guess this happens because some weird 12 or 24 hours conversion with HH being "00" changing the hour fixes the issue |
It's not an issue with parsing "00" as this works fine with other timezones. If you check https://www.timeanddate.com/time/change/egypt/cairo, your issue is most likely because daylight savings takes place exactly at that time where the clock will move forward an hour. This means the specified time is "non-existent" as it'll be 1am so I believe Apple's APIs return nil to represent this. It does work if 1am is specified and this looks like it would be the only solution that is likely only specific to iOS and macOS. From the plugin's side, this will be patched to trigger an error so at least it can be caught and have an explanation attached |
If you happen to know of a different solution, please do submit a PR but the one does the changes I spoke of can be found at #1951. Haven't merged it in and done a release to include this yet in case there are better solutions that I'm not aware of |
sorry for the late response
in dart send the full iso 8601 date to native side |
yes I thought of that it is weird really , I am from Egypt and we didn't have a daylight saving since years |
Thanks will need to investigate this more but sounds like my PR won't be needed then. It is better that there's a consistent way for the plugin to work on all platforms. Thought about the other formatter with ISO 8601 string but didn't get around to it. Not sure why the regular formatter doesn't work either. Perhaps Apple stopped maintaining it or that it fails as it's "confused" on how to parse the date and time in this scenario. If using the ISO 8601 is the way to go then will need to be careful that this doesn't break existing notifications for Android as the existing format is what gets saved to shared preferences to reschedule on reboot. It might be best create a separate variable for the date/time in ISO 8601 that is used only by iOS and macOS. By that I mean, to create an additional entry in the dictionary around flutter_local_notifications/flutter_local_notifications/lib/src/tz_datetime_mapper.dart Line 26 in 2a66c69
scheduledDateTimeISO8601 and that is what gets read on at least iOS and macOS. It may be possible to change Android to read from there going forward by adding a field etc to this class and remove the dictionary entry for scheduleDateTime but would still need to keep this line and the related logic for backwards compatibility. Would you by chance be up for creating a PR on this to the repo? Note that rather than committing straight to master on your fork, it is better that you create a separate branch as this allows master to be reserved for keeping up to date with the latest changes from the original repo
|
yes i understans yes i will do that |
Describe the bug
Choosing specific date crashes on specific regions leads to failure in parsing dates on iOs using "yyyy-MM-dd'T'HH:mm:ss
To Reproduce
example using latest package: (was tested on 13.0.0 and 14.0.0)
https://github.com/youssefali424/local_notification_test
Expected behavior
to not crash the app
Sample code to reproduce the problem
Sample code
The text was updated successfully, but these errors were encountered: