i have a Unix-based instant type called BSON.Millisecond
. it looks like this:
extension BSON
{
@frozen public
struct Millisecond:Hashable, Equatable, Sendable
{
/// Milliseconds since the epoch.
public
let value:Int64
}
}
this type isn’t very useful for date computation, so i was looking into ways to fit it into the semantics of InstantProtocol
, in the hope that it might reveal some useful API directions.
the problem i’m running into is that InstantProtocol
is quite wedded to the concept of a Duration
, and i am struggling to reconcile that with the durationless nature of time_t
.
naïvely, we might sketch an associated Duration
type for BSON.Millisecond
like:
extension BSON
{
@frozen public
struct Milliseconds:Hashable, Equatable, Comparable, Sendable
{
/// Number of milliseconds
public
let rawValue:Int64
}
}
extension BSON.Millisecond
{
public typealias Duration = BSON.Milliseconds
}
but InstantProtocol
has the requirements:
func advanced(by: Self.Duration) -> Self
func duration(to: Self) -> Self.Duration
they are completely undocumented as of 5.9, but based on how Strideable
works, it’s plausible to assume InstantProtocol
has the semantics
x.advanced(by: d) == y &&
x.duration(to: y) == d
for duration(to:)
, well that might go through difftime(_:_:)
which ought to handle leap seconds correctly. but i’m not aware of any way to implement advanced(by:)
in a consistent manner; the “C way” seems to be to just add seconds as an integer (1, 2) which can’t possibly handle leap seconds correctly, because leap seconds don’t exist in Unix dates.
i’m not sure what the solution is here, but some thoughts i have include:
-
Unix dates don’t have associated
Duration
types, they merely have “delta” types that must never be interpreted as quantities of time. for example, to advance a date by2 seconds
over a leap discontinuity, you would “advance” it by1 second
, even though the increment is a two second duration. -
if we accept that
duration(to:)
can be inconsistent withadvanced(by:)
, we should probably document that inInstantProtocol
. -
if not, are Unix dates even good candidates for an
InstantProtocol
conformance in the first place?