[regression] Date comparison with ms precision doesn't work anymore

[sebsto]

Describe the bug
On Swift 6.3 (aka nightly-main branch), comparing two dates expressing the same moment in time returns false, where it used to return true before.

To Reproduce

@main
struct TestDate {
    static func main() throws {
        #if canImport(FoundationEssentials)
        let dateString = "2020-01-13T09:25:40.621Z"
        let d1 = try Date(dateString, strategy: Date.ISO8601FormatStyle(includingFractionalSeconds: true))

        let d2 = Date(timeIntervalSince1970: 1_578_907_540.621)

        if d1 != d2 {
            fatalError("The two dates should be identical.  Got \(d1) and \(d2)")
        }
        print("Test OK")
        #else
        print("This test code runs with FoundationEssentials only, try running it on Linux.")
        print("✅ To test on Swift 6.2:")
        print("👉 docker run -v $(pwd):/app -w /app --rm swift:6.2 bash -c \"swift run\"")
        print("❌ To test on Swift 6.3:")
        print("👉 docker run -v $(pwd):/app -w /app --rm swiftlang/swift:nightly-main bash -c \"swift run\"")
        #endif
    }
}

Expected behavior
On Swift <=6.2, this test returns true.
On Swift 6.3 (nightly-main branch), it returns false.

Configuration (please complete the following information):
Docker images:
✅ swift:6.2
❌ swift:nightly-main

Regression information:
Works with Foundation and FoundationEssentials on Swift <= 6.2

Additional context
awslabs/swift-aws-lambda-events#102

I suspect this change to be the cause of this problem
https://github.com/swiftlang/swift-foundation/pull/1533/files

[sebsto]

FYI @stephentyrone @t089

[stephentyrone]

Date(timeIntervalSince1970: 1_578_907_540.621) actually constructs the date:

2020-01-13T09:25:40.6210000514984130859375

Because that's exactly the time that is represented by the TimeInterval 1_578_907_540.621 since 1970.

But 2020-01-13T09:25:40.621 isn't a double; it is a string specifying a time with milliseconds represented as a decimal, and Date can produce a more accurate value from it.

So these two Dates do not actually represent the same moment; they specify times that differ by about 51ns; they happen to have produced the same Date in the past due to rounding, but because we have made Date math more precise, these differences are expected to be observable.

Ideally tests such as this would use a tolerance on the comparison. For this specific case it would also suffice to compare the .timeIntervalSinceReferenceDate of the resulting Date objects.

[sebsto]

Thank you @stephentyrone for the analysis. I better understand the problem now. However, this raises a a few questions

• first, how did you get the .6210000514984130859375 value ? What field should we extra from Date to get that precision ?
• The code I show comes from a test suite where we verify the JSON decoding of strings that contain "2020-01-13T09:25:40.621Z". How to accurately very the parsing these strings ? What is the correct, official way to very that the parsed date is "2020-01-13T09:25:40.621" rounded to the milliseconds ?
• don't you expect a lot of code to break in existing app with this change of behaviour ? How can the developer be informed ? Is there anything the compiler can help with to detect this risk ?

[stephentyrone]

How did you get the .6210000514984130859375 value? What field should we extra from Date to get that precision?

Nothing to do with Date; I just wrote out the exact value of the fractional part of 1_578_907_540.621 after rounding to Double. You can get this by calling printf (or equivalently, String(format:_:)) with a format string of "%.32f" or similar.¹

How to accurately verify the parsing these strings?

Depends on what properties you are really trying to test. If you, say, want to ensure that the converted value is accurate to within half a millisecond, you could do something like the following:

abs(date.timeIntervalSince1970 - 1_578_907_540.621) < 0.0005

(Note that this compares it to the rounded value 1_578_907_540.621, which isn't quite right, but in this specific case it would suffice). More generally I would typically prefer to break the date back into its components and validate each of those, or to compare the computed Date to an extra-precise reference result.

don't you expect a lot of code to break in existing app with this change of behaviour? How can the developer be informed?

I expect a decent number of tests that are expecting to see the specific old rounding behavior to break with this change. I do not expect as many breakages for non-testing code, by virtue of the difference between how people write tests and how they use these types (it's common for people to write floating-point test code that expects a specific result, and which will break if that result is made more precise; however non-test software usually just silently benefits from the extra precision²).

Assuming that we keep this change, we'll put a release note in 6.3 explaining the rationale and how to work with the more-precise type and fix any broken tests.

Is there anything the compiler can help with to detect this risk?

These floating-point rounding issues are notoriously difficult for compilers to help with; frequently you'll hear people offer guidance like "never test floats for equality, always use a tolerance", but that sort of guidance is not absolutely true, so adding a compiler warning or fixit would also generate noise for perfectly legitimate uses of ==, which is generally undesirable.

---

¹ At least on Linux or macOS; The C standard does not require that printf be able to print so many digits, and on some other platforms it will not do so. On platforms that cannot print Double with extra precision, you can print a good approximation as follows:

let fractionalPart = 1_578_907_540.621 - 1_578_907_540 // exact, by Sterbenz' Lemma
print(fractionalPart) // 0.6210000514984131

² Usually. If people do find examples where non-test software is broken by this change, we're very interested in taking a look at them and seeing what we can do to help.