Implementation of ISO8601DateFormatter

[DunnCoding]

Implementation of the ISO8601DateFormatter with a suite of tests. I've been able to successfully run the tests on both mac and Linux.

I've also left the public required init?(coder aDecoder: NSCoder) and it's associated parts unimplemented for now.

[pushkarnk]

nit: We can call this file TestISO8601DateFormatter.swift if we are okay with dropping the NS prefix from the source file name as well

[pushkarnk]

nit: Since the class name does not have the "NS" prefix, it may make sense to drop it from the filename as well

[DunnCoding]

Yeah I agree, I'll remove the NS from this file and the test file as well.
Thanks for the review

[pushkarnk]

Since we're doing an unchecked unwrap here, are we sure this CF function will never return a nil?

[DunnCoding]

Given the limitations that are being placed on the values that can be passed into the CF function it shouldn't ever be able to return nil but I'm not 100% sure that is the case so I'll look into it. It may actually just be nicer if we just unwrapped the optional safely anyway rather than just using a force unwrap.

[pushkarnk]

@swift-ci please test

[alblue]

Seems like a test failure:

TestFoundation/TestISO8601DateFormatter.swift:38: error: TestISO8601DateFormatter.test_stringFromDate : XCTAssertEqual failed: ("2016-10-09T03:31:00Z") is not equal to ("2016-10-08T21:31:00Z") - 

[DunnCoding]

@alblue Thanks for that, seems the timeZone settings aren't being respected. I've added a fix that may solve the problem, would you be able to kick off the tests again?

Thanks.

[parkera]

@swift-ci please test

[pushkarnk]

Looks like the tests didn't run

@swift-ci please test

[pushkarnk]

cc @ddunn2
Seems like the tests have failed again

[alblue]

Looks like a similar problem to before:

Test Suite 'TestISO8601DateFormatter' started at 2017-05-31 00:59:04.860
Test Case 'TestISO8601DateFormatter.test_stringFromDate' started at 2017-05-31 00:59:04.860
TestFoundation/TestISO8601DateFormatter.swift:38: error: TestISO8601DateFormatter.test_stringFromDate : XCTAssertEqual failed: ("2016-10-09T03:31:00Z") is not equal to ("2016-10-08T21:31:00Z") - 

[alblue]

The code seems to be built around an assumption of what the current platform's timezone is:

       let someDateTime = formatter.date(from: "2016/10/08 22:31")
 +        let isoFormatter = ISO8601DateFormatter()
 +
 +        //default settings check
 +        XCTAssertEqual(isoFormatter.string(from: someDateTime!), "2016-10-08T21:31:00Z")
 +        

The 'someDateTime' will automatically pick up the time zone on your machine, which is presumably UTC+1 at the moment (which is why it's assuming your Z time is 21:31). Of course this is only true iff you're in summer time in Britain, or non-summertime in Europe. If you run locally with a different TZ set, you'll see different behaviour.

If you specify the date in a different way (for example, adding a Z at the end) then you may find these issues can be resolved fairly easily. Alternatively you may be able to test by switching your timezone to something else - probably by symlinking /etc/localtime to something else to see if you can replicate the errors listed on the build machine

$ ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  33 19 May 20:17 /etc/localtime -> /usr/share/zoneinfo/Europe/London

[alblue]

@ddunn2 can you resolve the conflicting TestFoundation/main.swift file please?

[DunnCoding]

@alblue Firstly, thanks for the spot on the tests. I overlooked that the DateFormatter I was using to construct the date would also be using some default time zone as well. I took your advice and ran the tests on a VM with the time zone changed and was able to recreate the errors. I've also added a fix that should mean the tests now pass.

I've fixed the merge conflicts, however TestMassFormatter.allTests was added, so need to look into why that is.

Thanks again for the help! 👍

[alblue]

@swift-ci please test

[alblue]

@swift-ci please test

[parkera]

Thanks!