-
Notifications
You must be signed in to change notification settings - Fork 2
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
Make opening hour selector clearer #39
Comments
Well the immediate reason is that using > 24 hour numbers for the next day is what the OH-spec requires, so that will be what we normally write to the OH string. From an UI pov, we don't necessarily have to use these numbers, but what it does need then is an indication that it is the next day otherwise there would be no way to differentiate between the two times with the same numerical value. |
I get it, but I think that if someone set the hours at 19:00-2:00 they intend the 2 of the following day. I think that nobody will think that if they set 19:00-2:00 they expect the program to set the tag as 2:00-19:00. |
The problem is that you have to differentiate in the selector itself say a time range from 06:00 to 29:00 |
I see the problem, but that's a very odd opening length and I don't think it occurs anywhere. I have a strange idea, but at the moment I can't edit images. I'll write back later when I've done the pictures. |
I think that the opening hours selector it's a bit weird if an user wants to set a time range that goes past midnight. I mean, why does it displays numbers as 23>24>25>26>...>48 and not 23>24>1>2>...>24? OSMAnd and Street complete they both use a clock to let the user set the opening hour tag and I think it's way more clear that counting up to 48.
The text was updated successfully, but these errors were encountered: