Fix Stats information fails to load when date cannot be parsed when returned from API

[staskus]

Fixes #22859

• Make sure WPKit Podspec is correctly updated

We need to pass yyyy-MM-dd date to API when fetching stats/visits and other similar endpoints. However, in some cases, date conversions to date string fails.

The bug is related to TimeZone and DTS. For example, Paraguay has a DTS change at midnight 2023-10-01 which is ambiguous to DateFormatter and nil is returned.

Date formatter we use:

private var periodDataQueryDateFormatter: DateFormatter {
    let df = DateFormatter()
    df.locale = Locale(identifier: "en_US_POSIX")
    df.dateFormat = "yyyy-MM-dd"
    return df
}

Result for "America/Asuncion" time zone:

df.timeZone = TimeZone(identifier: "America/Asuncion")
df.date(from: "2023-10-01") // result nil

Result for "Europe/Vilnius" time zone:

po df.timeZone = TimeZone(identifier: "Europe/Vilnius")
po df.date(from: "2023-10-01") // result <Date> 2023-09-30 21:00:00 +0000

In documentation Apple suggests to set the timezone to UTC:

When working with fixed format dates, such as RFC 3339, you set the dateFormat property to specify a format string. For most fixed formats, you should also set the locale property to a POSIX locale ("en_US_POSIX"), and set the timeZone property to UTC.

RFC3339DateFormatter.timeZone = TimeZone(secondsFromGMT: 0)

However, this is not a straightforward solution, since in Stats we're working with dates that are in a different time zone.

Solution

Created RFC339NoTimeDateFormatter that sets:

df.locale = Locale(identifier: "en_US_POSIX")
df.dateFormat = "yyyy-MM-dd"
df.timeZone = TimeZone(secondsFromGMT: 0)

but also recalculates the data to the current time zone after conversion. Therefore, the dates remain unchanged but conversions also succeed. I added RFC339NoTimeDateFormatterTests as an example.

To test:

The easiest way to reproduce and confirm that the issue is fixed is to follow the steps from #22859

1. Set defaultPeriodCount from 14 to 50 in SiteStatsTableHeaderView view so we can go back further back in dates
2. Switch the time zone to Paraguay/Asuncion
3. Open Stats Traffic tab
4. Select weeks
5. Come back to Sep 25 - Oct 1, 2023 week
6. Confirm data loads

Video before the fix

Date.bug.mov

Video after the fix

Date.fix.mov

Regression Notes

1. Potential unintended areas of impact

There shouldn't be any. WPKit-PR: wordpress-mobile/WordPressKit-iOS#771 adds unit tests to make sure that a new date formatter behaves in exact same way but additionally doesn't fail during DST changes.

2. What I did to test those areas of impact (or what existing automated tests I relied on)

Unit tests, manual tests

3. What automated tests I added (or what prevented me from doing so)

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing checklist:

• WordPress.com sites and self-hosted Jetpack sites.
• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• VoiceOver.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• iPhone and iPad.
• Multi-tasking: Split view and Slide over. (iPad)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr22910-478d749
	Version	25.1
	Bundle ID	org.wordpress.alpha
	Commit	478d749
	App Center Build	WPiOS - One-Offs #10214

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr22910-478d749
	Version	25.1
	Bundle ID	com.jetpack.alpha
	Commit	478d749
	App Center Build	jetpack-installable-builds #9263

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[staskus]

Update after #23366 is merged

[staskus]

This is a fix for a low-priority corner case. I only found this bug to be reproducible for Paraguay/Asuncion time zones during daylight savings date. 🤔 Therefore, I'm conflicted about whether it merits significant date formatter updates, although I tried to be careful and cover corner cases with tests.

[kean]

Dropping a note here as well, as it was discussed internally: it might be worth switching to native date here to eliminate any potential issues with timezones, time, and Date conversions.

[staskus]

I'm closing this PR based on the previous discussion. This is an extremely rare corner case that only happens when parsing a specific date in a timezone on which DST starts at midnight. Other more generic solutions are preferred.