| ▲ | stirlo 5 days ago | |
I wonder if this is because the code was just never looked at again after it was written or if it actually survived rewrites? Back in the day the iPhone was notorious for messing up alarm timezones and failing to activate with DST changes… https://www.abc.net.au/news/2011-01-03/alarm-failure-leaves-... | ||
| ▲ | ohdeargodno 5 days ago | parent | next [-] | |
It's written like this because making a circular, infinite list that repeats and recycles the same few components is awful to write, and "(0..60).times(50).flatten()" solves 99% of the problems with 1% of the effort. Product would probably raise this as a blocker after QA managed to scroll to the end. Who cares. | ||
| ▲ | yreg 5 days ago | parent | prev | next [-] | |
This is unrelated to timezones or Clock.app The limitation comes from the UIPickerView system level UI component. I have a similar "bug" in my app. | ||
| ▲ | hombre_fatal 5 days ago | parent | prev [-] | |
I bet it just happened organically. Started as an A…Z list but then someone had to implement it so that it cycled. And the simplest solution at the UI level is to make it a finite list that cycles multiple times. And that simple impl required no updates over the years despite changes to the UI toolkit. e.g. compare the HTML solution to one that is a virtualized JS infinite list. The HTML finite list solution is trivial while the infinite cycling one probably needs to be ported when you change frameworks (like move to SwiftUI). | ||