I don't think Timestamp or Time is any more clear than Date. It has the exact same potential for confusion, because a time is something people generally associate with a point inside a given day. Who really thinks of the current "time" as something that has incremented from some value starting in 1970 instead of "9:42 AM"?
Even if we could all agree on a name for a new type, we will not be wholesale replacing every instance of Date in Apple's SDKs with this new type, because Swift values source and binary compatibility. In my opinion, requiring an explicit conversion between this new type and others is a non-starter. Every new API from this point on would have to decide if it takes one of the two or both (doubling the API surface).
Let's say we then made them something equivalent to a typealias. API authors from this point on would have to make a decision if they want to appear to fit in with the SDK API and use Date or use the new name. Having participated in quite a few discussions about these APIs, I believe the SDK authors will choose to stick with Date for consistency, therefore leaving a permanent bifurcation of names and a splintering of what feels "right for Swift" vs "right for the SDK." Even on platforms with less history, this will still happen. One of the noted benefits of using Swift on server is its compatibility (both conceptually and in source) with the Swift you would write for the client side.
Believe it or not, I too wish we could go back and time and pick new names for some of our API, including Date. However, I think it is best to use the opportunity of sinking date to build this better infrastructure around it and to support it in the most compatible way possible.