Fix failing date tests

Previously we used an unlikely timezone: GMT+08h08m22s. This was used to test that converted dates were the same as one another.

However, it seems that now, iOS ignores or rounds down the seconds when creating a timezone. That resulted in test failures where we compared the seconds to `0` – under iOS 26, the actual value was 22, equal to the number of seconds after the last whole minute in the timezone we used.

I’ve made it an exact number of minutes to fix the test.

Author: joshheald

Modules/Tests/YosemiteTests/Model/Extensions/OrderStatsV4Interval+DateTests.swift

@@ -11,7 +11,9 @@ final class OrderStatsV4Interval_DateTests: XCTestCase {
                                             dateEnd: dateStringInSiteTimeZone,
                                             subtotals: mockIntervalSubtotals)
         // As long as the dates are parsed and formatted in the same time zone, they should be consistent.
-        let timeZone = TimeZone(secondsFromGMT: 29302)!
+        // Note that iOS 26 has changed behaviour here, and excess seconds in the timezone break the calculation
+        // This is 488 minutes, or 8 hours and 8 minutes
+        let timeZone = TimeZone(secondsFromGMT: 29280)!
         [interval.dateStart(timeZone: timeZone), interval.dateEnd(timeZone: timeZone)].forEach { date in
             let dateComponents = Calendar(identifier: .iso8601).dateComponents(in: timeZone, from: date)
             XCTAssertEqual(dateComponents.year, 2019)