SR-5837: Fix dateFormat bug in DateFormatter

[DunnCoding]

In a playground if you do the following:

let f = DateFormatter()
f.dateStyle = .long
f.timeStyle = .long
f.dateFormat

f.dateFormat at this point is equal to "MMMM d, y 'at' h:mm:ss a z"

However if you do the same in Foundation the f.dateFormat is equal to "" this is because whenever you set the Style properties dateFormat is being set to nil but it's not then reassigned a new value at that point. The code handles this nil value by assigning dateFormat the value of "" but this is not the correct value.

The expected behaviour is that when you set the Style properties the dateFormat property is then also reassigned the correct value based on the value you assigned to the Style properties.

This PR fixes this behaviour and ensures dateFormat is being set whenever the the Style properties are being set. I've also opened a bug for this which you can find here

[parkera]

@swift-ci please test

[ianpartridge]

@swift-ci please test

[DunnCoding]

I've updated the test coverage for this issue, in doing so I found a difference in behaviour in the construction of the dateFormat string.

This issue can be seen if you set the dateStyle property to .medium and then set the timeStyle property to anything other than .none.

Here is an example:

let f = DateFormatter()
f.dateStyle = .medium
f.timeStyle = .long
f.dateFormat

In a playground f.dateFormat is equal to "MMM d, y 'at' h:mm:ss a" however the result of the corresponding method in Foundation returns the following format, "MMM d, y, h:mm:ss a". The construction of these Strings seem to happen in CoreFoundation so for now I've left those cases commented out. I've also omitted the cases of .full as these are currently not working correctly on Linux.

[ianpartridge]

@swift-ci please test

[ianpartridge]

@parkera any thoughts about this difference in CF behaviour with dateStyle = .medium? Probably another ICU incompatibility?

[spevans]

Ive seen this issue with ICU on Linux even using a C program interfacing directly to ICU bypassing Swift / CoreFoundation.

[parkera]

One of these days we're going to have to enforce a specific version of ICU to use with swift-corelibs-foundation. In the past there were objections to this idea since it would increase the size of the distribution, but that may not matter as much any more.

[spevans]

The swift build script actually has support for building ICU as part of the build although libxml2 also links to libicu so would need to be built somehow.

However in my testing I tested upto 57.1 (which was reasonably recent) and it still exhibited these issues on Linux. Does Apple do any customisation for its build of libicucore ?

[parkera]

Yah, you can see the Apple ICU release here: https://opensource.apple.com/release/macos-10125.html

[ianpartridge]

@swift-ci please test and merge