CLKRelativeDateTextProvider in timer mode displays inaccurate information when [.hour, .minute] units are set

Originator:jose.castillo
Number:rdar://35241091 Date Originated:10/29/2017
Status:Open Resolved:
Product:watchOS + SDK Product Version:watchOS 4.0 (15R372)
Classification:Other Bug Reproducible:Always
 
Summary:
CLKRelativeDateTextProvider provides a timer mode where developers can have a complication count up or down from a specified date. It also provides a calendarUnits variable that allows developers to specify which units we wish to have displayed in the complication. 

However, when providing units of [.hour, .minute] in timer mode, with a relative date less than an hour from the current date, the behavior of the CLKRelativeDateTextProvider becomes broken in two ways: 

1. The requested units are not respected. The complication displays minutes and seconds until the relative difference is greater than one hour, at which point the complication begins correctly displaying hours and minutes.
2. Despite displaying seconds, the complication only updates once per minute, freezing the MM:SS display in place until the user causes the complication to redraw (raises wrist, invokes Time Travel, etc).


Steps to Reproduce:
1. Create a CLKRelativeDateTextProvider with the following options: CLKRelativeDateTextProvider(date: Date(), style: .timer, units: [.hour, .minute])
2. Install that date provider in a CLKComplicationTemplate and set it on the watch face.

Expected Results:
The complication will count up minutes from the current date: 0:01, 0:02, 0:03, until it reaches the one hour mark, at which point it will continue: 0:59, 1:00, 1:01

Actual Results:
When there is only room for two units, the complication will begin displaying the number of minutes and seconds from the timer start, frozen in place until the user raises their wrist (potentially displaying numbers like 2:37, 21:35, 56:47) until it reaches the one hour mark, at which point it will begin counting the time 1:00, 1:01, 1:02. 


Notes: 
I have provided a test project that demonstrates this issue. It displays a two line complication, where the first line counts up from the start time, and the second line counts down to the end time. You can set the complication in the Modular Large/Small, Circular or X-large slot. 

In the watch app, tap the "Start 10m Timer" button to see the intended behavior. It configures the timers with units of [.minute, .second]. The first line correctly counts up from 0:00 and the second line correctly counts down from 10:00.

Tap the "Start 3h Timer" button to see the bug. It configures the timers with [.hour, .minute] units. In the small slots, you'll see the top line stuck at some number of minutes and seconds, while the bottom line counts down from 2:59. In the Modular Large slot, you will also notice that both lines display seconds (2:59:45), despite the fact that we asked for them to be omitted. Both lines incorrectly display the seconds as frozen, and only update the labels once per minute.


Version/Build:
watchOS 4.0 (15R372)


Configuration:
Apple Watch Series 2 SS running watchOS 4.0 (15R372), iPhone 8 Plus running iOS 11.0.3 (15A432)

Comments

Same issue here

I am facing the same issue as well. When more than an hour is remaining, it shows HH:MM. Once it is below 60 minutes it starts showing MM:SS. So when the complication shows 7:00, it can be either "7h 0m" or "7m 0s". This will confuse the hell out of the customer.

There is another problem as well with ".timer" style. For ".natural" style with units = [.hour, .minute], the remaining time gets rounded up. For example if the remaining time is 4:15:30, it will show "4HRS 16MIN". This is nice as it matches (adds up) with the time displayed on the clock. On the other hand the ".timer" style rounds it down and shows "4:15". Due to this, when both modularSmall (.timer) and modularLarge (.natural) complications are on the watch face, they are off by 1 minute.

I tried to compensate for this by adding 60 seconds to the endDate for modularSmall complication. Worked really well until the remaining time came down under 1 hour, at which point it started showing the MM:SS format, with the added 60 seconds making it appear wrong.

For the time being, my workaround is to split one timeline entry into the following two. 

    * startDate       To     endDate + 60 seconds     // with units = [.hour, .minute]
    * endDate - 1Hr   To     endDate                  // with units = [.minute, .seconds]

When .second is included in the units, it seems to update the complication every second, instead of being frozen at random seconds.

By mpathitech at Jan. 16, 2019, 2:51 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!