Sol: Sun Clock finally gets a system overhaul in version 4, which is now live on the App Store. First, let me extend a THANK YOU to all the users and beta testers who provided invaluable feedback, notes, and screenshots. We thrive on making apps that actual users find useful and fun to use, and we can’t do that without great feedback.
In 4.0 , aesthetically, very little has changed— many users may have missed it, but the scrolling area under the date is now on by default, and I’ve fixed the bug that allows it to keep scrolling if you left it on from the last use. The Almanac page now shows information for the whole day instead of the precise moment. There are some minor textual changes here and there.
The real updates are almost all “under the hood” — I’ve made a number of changes to the date/time system and other key code methods that will result in a much more reliable experience, removing (I hope) all the “outlier” bugs that some users experienced more than others.
You may not even notice but one change is that the colored wheel (or “pie”) that you spin is now not a 24-hour period, but is now a solar day, which can deviate from 24 hours by as much as 30 seconds, depending on the time of year. (Check out the Wikipedia article on the equation of time if you’re curious why this is.)
So now, halfway through the wheel (180 degrees) will now correspond exactly with solar noon, and 0 degrees with solar midnight. Swiping forward or backwards across the date field, or tapping on it to change days will leave you at the same position in the solar day, not the same clock time, so you’ll be able to see the way the daylight changes from day to day easier.
We had a handful of users write to say that the forward and back arrow buttons (to go forward or back to the next period or event) weren’t working for them. This was because of this up-to-30 second differential between the solar day and the 24-hour day. Looking at this chart, the times when the deviation was greatest coincided with users’ problems.
The date at the top is now the date of the solar day and not the clock time for your present location (or for the location that you’ve chosen). There may be up to an hour or two between midnight and solar midnight, depending on your position within your time zone and whether or not you’re in Daylight Saving Time , where you’re in one solar day and a different day for the clock time. (If you’ve set the time zone to be a different time zone than the location you’re looking at, it could be even longer.) In these cases, the date at the top still shows the solar day, but there will be “+1 day” or “-1 day” next to the clock time, above the time zone display.
Likewise, when you set an alarm, you’re setting the date of the solar day and not the day of the apparent clock time. This should fix many of the issues with alarms people were having. They may have had it to repeat on Tuesdays, but the clock’s Tuesday in GMT may be your Monday in your time zone. When the sun’s at it’s zenith (solar noon), that’s the middle of the solar day, and that’s the date that you’re seeing at the top of the screen and in the alarm setting now. We think that is actually more intuitive, and makes for much cleaner and straightforward code as well, and should address most of the time issues with alarms that a few users reported.
We made many other changes, too that will hopefully make the app work more efficiently. Although the app now requires iOS 8.0 instead of 7.0, having looked at our analytics, fewer than 4 in 1000 of our users are on 7.0 or older — so we feel like using the modern compiler Apple provides with the new Xcode will benefit many, many more users than it will hurt.
We’ve also been able to implement a new time zone lookup library, and show daylight saving time (aka summer time) changes on the wheel.
And finally, technical note/confession, for programmer-types: this is the first version of Sol to have an extensive unit test suite. I was hesitant to learn how to do this in Xcode, because my queue of skills I’d like to learn has always tended to give higher ranking to more “exciting” technologies, and it’s hard to even say “unit test” without getting a little bit sleepy. But it turned out to be essential for reworking the code and having the confidence that I was making the right decisions as I went forward. It was a great move, and I highly recommend it for anyone dealing with complex (and not-so-complex) code.
And with every revision of Sol, I feel like I have mastered all the complexities dealing with calendar systems, time zones, daylight saving time, and Apple’s libraries to deal with those (NSCalendar, NSTimeZone, NSDate, NSDateComponents, etc), and it turns out there’s always one thing I didn’t quite understand. The previous version of Sol made the assumption that all the issues were related to daylight saving time issues, while actually the most important concept to fix issues with Sol was to decouple the 24-hour day and the solar day completely.
Also using a Gregorian date in NSDateComponents of just year, month and day to tie to the solar day, while using the user’s current locale and settings to show the time in whatever format they want turned out to be the way to go, instead of using an NSDate in UT/GMT and trying to figure out which actual day we wanted (could be either +/- one day depending on your time zone). That way the conversions only went one way, from the more generic Gregorian day to the more specific, customized date and time for the user’s locale. The assumption that UT/GMT was the way to go was made because generally in computer science it is, but was not in this case.
Also as a few users noticed, Daylight Saving Time did continue to be an issue, despite many attempts to address it in past versions. One of the offending functions turned out to be secondsSinceStartOfDay which was used to draw parts of wedges on the wheel and translate between rotation of the wheel and the time of day. On days with DST transitions, 3am could either be 4 hours or 2 hours since midnight, and what to do with the lost or extra hours? If you used a UT calendar, there is no daylight saving adjustment, but that only solves half the problem—you still have to translate it for the user’s expectation of what day it is. By going with the gregorian solar date, and only translating into the user’s locale at the time of display, many of these issues were easier to attack…. but enough about that!
Finally, I decided to call this version 4.0 for several reasons — first, that while many of these could be considered bugfixes, and while there are only a few minor changes to the UI, it was far more than the week’s work I thought it needed (and about 75 git commits) — several months later I realized that while the app looked basically the same, enough had changed under the hood. Plus, the app now requires iOS 8.0, which isn’t an issue for 99% of our users. If you’re the 1%, hopefully you can get by using the old version.
There are a lot of other additions that I have planned for the future (yes, including adding the moon!), and thanks to everyone for their feature requests. The best way to contact us about bugs and features is within the app itself. Find the settings/gear icon, and select Feedback. Thanks so much!
Official page for Sol: Sun Clock
Sol: Sun Clock on the App Store
Twitter page for Sol: Sun Clock
Facebook page for Sol: Sun Clock
More articles about Sol: Sun Clock on the blog.