Stats Traffic: Card information fails to load when date cannot be parsed when returned from API

[staskus]

self.periodDataQueryDateFormatter.date(from: "2023-10-01") returns nil resulting in "An error occurred" messages shown on Stats Traffic cards

From #22826 (review)

An error occurred when viewing certain weeks

I thought it might be related to Oct having six calendar weeks, but it looks to be related to DST kicking in in my timezone on Oct 1st.

On the team P2 with the week of "Sep 25 - Oct 1, 2023" selected, the screen doesn't load and `An error occurred" is shown:

self.periodDataQueryDateFormatter.date(from: "2023-10-01") returns nil for me, which ends up being due to clocking moving forward one hour at that time. Adding df.timeZone = TimeZone(secondsFromGMT: 0) seems to fix the issue.
This is unrelated to this PR, so not a blocker.

[dangermattic]

Thanks for reporting! 👍

[staskus]

The bug is reproducible and looks to be tightly related to TimeZones and DTS. The one used in Paraguay has a DTS change at midnight 10-01 which is ambiguous to DateFormatter and nil is returned. Even similar examples from StackOverflow reference Paraguay timezone with this particular bug.

DateFormatter:

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

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

nil

po df.timeZone = TimeZone(identifier: "Europe/Vilnius")
po df.date(from: "2023-10-01")

▿ Optional<Date>
  ▿ some : 2023-09-30 21:00:00 +0000
    - timeIntervalSinceReferenceDate : 717800400.

Solution

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 the dates that are in site's timezone.

[staskus]

Closing as won't fix. See #22910 (comment)