I think the GCD wrappers for dispatch_time_t are broken. The type is an opaque type. To understand why, one needs to look at the implementation. The dispatch_time_t type is a union of two very different notions of time:

1. Mach absolute time, which pauses while the system is asleep and doesn't promise long-term precision.

2. Unix "wall time", which does not pause during system sleep and promises consistent [albeit lower] precision over time.

The pausing versus not behavior makes comparing two dispatch_time_t values meaningless.

Last I knew, the encoding of the C "union" was roughly like so:

if (dt == 0) {
  // "now" -- typically used with timeout based APIs
} else if (dt == ~0) {
  // "forever" -- typically used with timeout based APIs
} else if (dt > 0) {
  // Mach absolute time -- typically used with timeout based APIs
} else {
  // Unix wall time (encoded via two or one's complement, I don't remember); probably used with a timer
}

DispatchTime and DispatchWallTime are distinct types for swift. Since it isn't possible to initialize one from a raw value, they're internally consistent.

Well look at that. Interesting. FWIW – the intention of the C dispatch time API was merely as a way to feed values into GCD. It wasn't meant to be a replacement or superset of existing time APIs. I'd just look at the Swift extensions to the underlying C API as a curiosity.

cc ktopley-apple (JIRA User)

@davezarzycki: There is no claim that it is "a replacement or superset of existing time APIs". However, it is convenient to use libdispatch's own formats whenever dealing directly with libdispatch – and it should work correctly.

Comment by David Grove (JIRA)

The two copies of Time.swift in the Dispatch overlay are out of synch. The one used on Linux (swift-corelibs-libdispatch/src/swift/Time.swift) has:

public func <(a: DispatchTime, b: DispatchTime) -> Bool {
    if a.rawValue == ~0 || b.rawValue == ~0 { return false }
    return a.rawValue < b.rawValue
}

while the Darwin one (swift/stdlib/public/SDK/Dispatch/Time.swift) has

public static func < (a: DispatchTime, b: DispatchTime) -> Bool {
 return a.rawValue < b.rawValue
 }

Which matches the behavior reported by @glessard.

I think someone at Apple (ktopley-apple (JIRA User) ? ) needs to decide on the desired semantics of < on DispatchTime and then the fix for this bug is simply to get that semantics into both versions.

Comment by David Grove (JIRA)

fwiw, I suspect the right code is actually a third variant:

public func <(a: DispatchTime, b: DispatchTime) -> Bool {
     if a.rawValue == ~0 { return false }
     if b.rawValue == ~0 { return true }
     return a.rawValue < b.rawValue
 }

Comment by Kim Topley (JIRA)

I filed Radar 34132958 to synchronize the two versions of Time.swift.

dgrove-oss (JIRA User): that 3rd variant was exactly the patch I tried, only to see no change. I didn't realize there were two versions of the overlay!

#182 contained the fixes in apple/swift#5078 but it was abandoned without having been (fully) merged.

Comment by Kim Topley (JIRA)

The changes to the Linux overlay are in a branch awaiting review (#298

The Darwin code is the correct version. There is no need to have special cases for ~0, because rawValue is of type dispatch_time_t, which is uint64_t and therefore the comparison "a.rawValue < b.rawValue" is unsigned.

Nice! I somehow missed this earlier. Thanks

fixed in 4.2.3 (must have been fixed before that)