You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During development one could encounter having a date with is an invalid time table date.
I think that an date is none UTC conform is probably the most likely reason. But it could also be null.
Asserting the value at various points with isValidTimetableDateTime is a great way to ensure this does not happen during development how ever if this happens the developer can not be certain for what reason it is not since there is no specific assertion message attached.
I took a look at the code and I'm not quite sure if this is an easy fix due to the nature of assertions nor am I quite sure if this is really something the library should do for the developer. Hinting him to the assertion error(s) quite does the task.
How ever it would be quite convenient when you believe you are searching for null values in your code but the date is simply UTC formatted.
What do you think?
The text was updated successfully, but these errors were encountered:
dateTime.isValidTimetableDateTime only checks that the DateTime has isUtc set. For nullable DateTimes, null is also allowed. This is true for all isValidTimetable… checks.
I can add a message (or, maybe, use FlutterError) to this and other checks to make clearer what is expected of these values, similar to the note in the README.
I don't think this has high priority. This is more a convenience point but I still believe that it might be helpful. I might help you out if you are interested. Adding an optional error message to assertions should be pretty straight forward.
During development one could encounter having a date with is an invalid time table date.
I think that an date is none UTC conform is probably the most likely reason. But it could also be null.
Asserting the value at various points with
isValidTimetableDateTime
is a great way to ensure this does not happen during development how ever if this happens the developer can not be certain for what reason it is not since there is no specific assertion message attached.I took a look at the code and I'm not quite sure if this is an easy fix due to the nature of assertions nor am I quite sure if this is really something the library should do for the developer. Hinting him to the assertion error(s) quite does the task.
How ever it would be quite convenient when you believe you are searching for null values in your code but the date is simply UTC formatted.
What do you think?
The text was updated successfully, but these errors were encountered: