0

On iPadOS 13, when the user sets "24-hour time" to FALSE, the following code would produce the following output:

Code:

+ (NSString *)dateStringFromDate:(NSDate *)date {
    NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
    [dateFormatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss'Z'"];
    return [dateFormatter stringFromDate:date];
}

Output:

2020-10-19T11:55:29Z

But, on iPadOS 14, the same code produces this output:

2020-10-19T12:38:06 p.m.Z

Note: the 24-hour time toggle was set to FALSE on both operating systems. For some reason, iPadOS 14 seems to be respecting the AM/PM setting in the NSDateFormatter, but iPadOS 13 was not.

I know that setting the locale to this will remove the AM/PM entirely:

dateFormatter.locale = [NSLocale localeWithLocaleIdentifier:@"en_US_POSIX"];

But, we are trying to understand why the problem only occurs on iPadOS 14 and not 13 when the iPad settings are exactly the same.

Mike Buss
  • 980
  • 9
  • 25
  • Instead of wondering why, why not just use the posix locale like you're supposed to and move on? You _know_ your code is wrong, so just abandon it. – matt Oct 23 '20 at 18:26
  • In my opinion, understanding why it broke is important to make sure it, and things like it, won't break in the future. This code was working like clockwork for 4 years and then broke, so I'd like to make sure the fix is sufficient. There's also a curiosity component to it! – Mike Buss Oct 24 '20 at 00:49
  • Well, you were lucky, someone from Apple came along and told us the answer! Maybe worth filing a bug. – matt Oct 24 '20 at 01:12

1 Answers1

2

Foundation's date and time APIs are built on top of a version of ICU that ships with Apple platforms. Between OS releases, both Foundation and ICU code receive updates, which fix old bugs, and occasionally introduce new bugs. At whatever API layer the change here has manifested (and whether this is considered a bug at that layer), you're seeing the consequence of code having changed.

The behavior here does not look right, but luckily, a locale of en_US_POSIX (which you should likely be setting anyway) resolves the issue.

Itai Ferber
  • 28,308
  • 5
  • 77
  • 83